headers
dan marsden | 6 Apr 13:58
Picon

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

Permalink | Reply |
headers
vicente.botet | 6 Apr 18:05
Picon

Re: 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
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 6 Apr 18:18
Picon

Re: Egg 2nd request for reviews: Some comments

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

Permalink | Reply |
headers
shunsuke | 6 Apr 20:55
Picon

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

Permalink | Reply |
headers
vicente.botet | 6 Apr 22:53
Picon

Re: Egg 2nd request for reviews: Some comments

I think that I start to understand.

_____________________
Vicente Juan Botet Escriba

----- Original Message ----- 
From: "shunsuke" <pstade.mb <at> gmail.com>
To: <boost <at> 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;
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 6 Apr 19:14
Picon

Re: Egg 2nd request for reviews: Some comments

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

Permalink | Reply |
headers
shunsuke | 6 Apr 21:10
Picon

Re: 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?

> It would be very nice if the docummentation contains links for the macros
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 6 Apr 22:58
Picon

Re: Egg 2nd request for reviews: Some comments

----- Original Message ----- 
From: "shunsuke" <pstade.mb <at> gmail.com>
To: <boost <at> 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:
>
(Continue reading)

Permalink | Reply |
headers
shunsuke | 6 Apr 23:33
Picon

Re: Egg 2nd request for reviews: Some comments

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
shunsuke | 6 Apr 20:40
Picon

Re: 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.
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
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 6 Apr 22:51
Picon

Re: Egg 2nd request for reviews: Some comments

Hi,

thanks for your QUICK answer :-)

----- Original Message ----- 
From: "shunsuke" <pstade.mb <at> gmail.com>
To: <boost <at> 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.
(Continue reading)

Permalink | Reply |
headers
shunsuke | 6 Apr 20:10
Picon

Re: Egg 2nd request for reviews

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

Let me summarize the discussion so far.

Giovanni Piero Deretta pointed that:
   adapting function macros can be removed in the case of stateless functions.
Eric Niebler pointed that:
   duplicated metafunctions make users confused.

So, I'm inclined to introduce a new `static_` form.
It goes like this:

     The adapting form in review version:
         result_of_curry2<F>::type const c = BOOST_EGG_CURRY2({}); // stateless
     is changed to a new `static_` form *without macros*:
         static_< result_of<T_curry2(F)> >::type const c = {{}};
     ( In fact, it has been supported also in review version, but slightly cumborsome:
         static_< mpl::always<result_of<T_curry2(F)>::type> >::type const c = BOOST_EGG_STATIC();  )

How do you think about this new `static_` form?

Regards,

--

-- 
Shunsuke Sogame
(Continue reading)

Permalink | Reply |
headers
Kirit Sælensminde | 7 Apr 10:38
Picon

Re: Egg 2nd request for reviews

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

I'd really like to do a review, but so far have only found time to start 
to read the documentation.

So far I think the documentation is pretty good. One thing that I 
especially like (and I wish more of the Boost documentation would do) is 
to list the required headers with each example. I agree though that 
adding egg:: to the egg members would probably make things clearer.

I like the Haskell examples for egg::nest, but didn't notice that the 
documentation was explicit about stating it was Haskell - some probably 
won't recognise it.

Really I need to have a good play around with it, but I don't know when 
I will have time to do so :( Almost certainly not in the next two weeks 
though.

K
Permalink | Reply |
headers
shunsuke | 7 Apr 20:54
Picon

Re: Egg 2nd request for reviews

Kirit Sælensminde wrote:
> So far I think the documentation is pretty good. One thing that I 
> especially like (and I wish more of the Boost documentation would do) is 
> to list the required headers with each example.

Maybe I should put a hyperlink to example cpp file.

> I agree though that 
> adding egg:: to the egg members would probably make things clearer.

Ok.

> I like the Haskell examples for egg::nest, but didn't notice that the 
> documentation was explicit about stating it was Haskell - some probably 
> won't recognise it.

I should put some hyperlink about haskell notation.

> Really I need to have a good play around with it, but I don't know when 
> I will have time to do so :( Almost certainly not in the next two weeks 
> though.

The review manager will consider it. :-)

Regards,

--

-- 
Shunsuke Sogame
Permalink | Reply |
headers
Steven Watanabe | 9 Apr 16:40
Picon

Re: Egg 2nd request for reviews

AMDG

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

I'll try to do a review, but I don't really have time till the end of 
the week.

In Christ,
Steven Watanabe
Permalink | Reply |
headers
Giovanni Piero Deretta | 11 Apr 17:12
Picon

Re: Egg 2nd request for reviews

On Sun, Apr 6, 2008 at 1:59 PM, dan marsden <danmarsden <at> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 11 Apr 17:25
Picon

Re: Egg 2nd request for reviews

On Fri, Apr 11, 2008 at 11:12 AM, Giovanni Piero Deretta
<gpderetta <at> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
dan marsden | 11 Apr 21:46
Picon

Re: Egg 2nd request for reviews

><gpderetta <at> 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

I do intend to extend the review period by a week. I appreciate that Egg
is a big library, and it takes a bit of time to review fully. So no need
to rush a review, but please do put them in before the end of next week.
Currently the review count sadly still sits at zero, so your reviews will
be gladly received thanks!

Cheers

Dan

      ___________________________________________________________
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 12 Apr 18:40
Picon

Re: Egg 2nd request for reviews

On Fri, Apr 11, 2008 at 3:48 PM, dan marsden <danmarsden <at> yahoo.co.uk> wrote:
> ><gpderetta <at> 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
>
> I do intend to extend the review period by a week. I appreciate that Egg
> is a big library, and it takes a bit of time to review fully. So no need
> to rush a review, but please do put them in before the end of next week.
> Currently the review count sadly still sits at zero, so your reviews will
> be gladly received thanks!

Unfortunately, I believe I'm going to have to renege on my review.
After spending some time with Egg, I see that its scope goes way
beyond my initial interest. I'm afraid I can't do it justice in a
review at this time. However, I will share some of my first
(Continue reading)

Permalink | Reply |
headers
Giovanni Piero Deretta | 12 Apr 20:14
Picon

Re: Egg 2nd request for reviews

On Sat, Apr 12, 2008 at 6:40 PM, Daniel Walker
<daniel.j.walker <at> gmail.com> wrote:
> On Fri, Apr 11, 2008 at 3:48 PM, dan marsden <danmarsden <at> yahoo.co.uk> wrote:
>  > ><gpderetta <at> 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
>  >
>  > I do intend to extend the review period by a week. I appreciate that Egg
>  > is a big library, and it takes a bit of time to review fully. So no need
>  > to rush a review, but please do put them in before the end of next week.
>  > Currently the review count sadly still sits at zero, so your reviews will
>  > be gladly received thanks!
>
>  Unfortunately, I believe I'm going to have to renege on my review.
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 15 Apr 04:48
Picon

Re: Egg 2nd request for reviews

On Sat, Apr 12, 2008 at 2:14 PM, Giovanni Piero Deretta
<gpderetta <at> gmail.com> 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,
(Continue reading)

Permalink | Reply |
headers
shunsuke | 13 Apr 00:26
Picon

Re: Egg 2nd request for reviews

Daniel Walker wrote:
> Egg seems to have a lot of valuable components that may fill a niche
> in the existing paradigm for functional programing in C++, but the
> shape of that niche is changing as more classic boost techniques are
> transmuted into the standard and newer boost libraries come online. So
> there's an unfixed boundary between advancing the cause of functional
> programing and reinventing existing primitives. 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?

For Egg, named parameters facility also should be a FunctionAdaptor.
E.g.
   named(plus)(left=1, right=2);
Actually old Egg had such a FunctionAdaptor.
I removed it in honor of Boost.Parameter.

> 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.)

Assume std_bind is a FunctionObject type which represents std::bind:
   X_lazy<std_bind> std_lazy;
   std_lazy(plus)(_1, 2)(1);

std::bind can be a customization point of egg::lazy.
(Continue reading)

Permalink | Reply |
headers
Daniel Walker | 15 Apr 05:04
Picon

Re: Egg 2nd request for reviews

On Sat, Apr 12, 2008 at 6:26 PM, shunsuke <pstade.mb <at> gmail.com> wrote:
> Daniel Walker wrote:
> > Egg seems to have a lot of valuable components that may fill a niche
> > in the existing paradigm for functional programing in C++, but the
> > shape of that niche is changing as more classic boost techniques are
> > transmuted into the standard and newer boost libraries come online. So
> > there's an unfixed boundary between advancing the cause of functional
> > programing and reinventing existing primitives. 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?
>
> For Egg, named parameters facility also should be a FunctionAdaptor.
> E.g.
>   named(plus)(left=1, right=2);
> Actually old Egg had such a FunctionAdaptor.
> I removed it in honor of Boost.Parameter.

Maybe there's some way it could come back... either using
Boost.Parameter or being used by Boost.Parameter. I'm not sure, and
named parameters are not a must have feature for me. I'm just trying
to see where Egg fits into the larger picture.

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

Permalink | Reply |
headers
shunsuke | 15 Apr 07:52
Picon

Re: Egg 2nd request for reviews

Daniel Walker wrote:
>> std::bind can be a customization point of egg::lazy.
>> IMO, bind interface is legacy.
>> (In fact, to implement std_bind is too difficult,
>>  and bll::bind is enough. So, Egg skips it.)
> 
> See, I think of std::bind as becoming a staple - something that
> programmers will use as commonly and readily as std::vector. I would
> look at std::bind as a primitive, fundamental idiom of functional
> programming in C++, which functional programming libraries should
> build on and extend. By doing so you build on the existing
> expectations and expertise of potential users, which lowers barriers
> to adoption and generally makes their lives easier.

I really agree that we must appreciate the standard.
Hence, I designed egg::lazy so that it can support std/boost::bind.

Regards,

--

-- 
Shunsuke Sogame

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

Gmane