<gpderetta@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 ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
On Fri, Apr 11, 2008 at 3:48 PM, dan marsden <danmarsden@yahoo.co.uk> wrote:
<gpderetta@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 impressions. 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. 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. 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? 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.) Still, I think it is a noble ambition to create the equivalent of Boost.Iterator for functions - i.e. to do for std::unary_function and std::binary_function what Boost.Iterator did for std::iterator. Surely Egg represents progress toward that goal. Perhaps if Egg were repackaged/refocused to become a more comprehensive Boost.Function (a true counterpart to Boost.Iterator: intuitive and accessible), it would draw wider interest. I'm not sure though, because by nature functors may be harder to package/sell than iterators. FWIW, I did build and run Egg's test suite using gcc 4.3 with both -std=c++98 and -std=c++0x. The test suite is large and seems to have good coverage. It ran with only one apparently minor glitch, which is testimony to the quality of Egg's implementation. Egg is certainly an accomplishment. Shunsuke, later this weekend I'll try to send you the test suite output and a few other comments off-list. Daniel Walker
On Sat, Apr 12, 2008 at 6:40 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On Fri, Apr 11, 2008 at 3:48 PM, dan marsden <danmarsden@yahoo.co.uk> wrote:
<gpderetta@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.
that's unfortunate! :(
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 impressions.
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.
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)
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.
I think that mainstream C++ is nowhere near to what FC++ could provide 5 years ago. Egg brings it a bit closer.
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.
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)
Still, I think it is a noble ambition to create the equivalent of Boost.Iterator for functions - i.e. to do for std::unary_function and std::binary_function what Boost.Iterator did for std::iterator. Surely Egg represents progress toward that goal. Perhaps if Egg were repackaged/refocused to become a more comprehensive Boost.Function (a true counterpart to Boost.Iterator: intuitive and accessible), it would draw wider interest.
I agree with that.
I'm not sure though, because by nature functors may be harder to package/sell than iterators.
we will have to wait and see :). -- gpd
On Sat, Apr 12, 2008 at 2:14 PM, Giovanni Piero Deretta <gpderetta@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, 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
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. IMO, bind interface is legacy. (In fact, to implement std_bind is too difficult, and bll::bind is enough. So, Egg skips it.)
FWIW, I did build and run Egg's test suite using gcc 4.3 with both -std=c++98 and -std=c++0x. The test suite is large and seems to have good coverage. It ran with only one apparently minor glitch, which is testimony to the quality of Egg's implementation. Egg is certainly an accomplishment. Shunsuke, later this weekend I'll try to send you the test suite output and a few other comments off-list.
Thanks. -- Shunsuke Sogame
On Sat, Apr 12, 2008 at 6:26 PM, shunsuke <pstade.mb@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 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. 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. Daniel
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
participants (4)
-
dan marsden -
Daniel Walker -
Giovanni Piero Deretta -
shunsuke