[Review] Phoenix review starts today, September 21st
Hi all, The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. History: Phoenix is a mature library from years of use as a sub-project under Spirit where it serves its purpose for semantic action handling. Phoenix predates Lambda's acceptance into Boost, but not Lambda itself. When Lambda was reviewed, it was concluded that both libraries were to be merged, and work on it began, culminating in Phoenix V2, what you are seeing now (an interesting offshoot of this effort is Boost.Fusion. We needed a powerful tuple facility with algorithms to get the design right). Recently, Eric Niebler did a (fully compatible) port to proto making use of boost.typeof for result type deduction. Eric's port, while significant, will not be the subject of the review, but can be regarded as the future of Phoenix (Phoenix V3). Phoenix V2 is currently a utility library included with Spirit V2 and therefore is already available from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/index.html) Phoenix V2 is a very important infrastructure library, IHMO. It has been used for several other library writing efforts already, most notably, Spirit V2. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager
Hartmut Kaiser wrote:
The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists!
Just a question, why review v2 and not v3, which addresses some of v2 issues like non-standard type deduction protocol? It also should have a clearer implementation, even if it may not be as efficient.
Mathias Gaunard wrote:
Hartmut Kaiser wrote:
The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists!
Just a question, why review v2 and not v3, which addresses some of v2 issues like non-standard type deduction protocol?
Because it's not ready yet V3 is in alpha. V2 OTOH had years of deployment behind it. It's already in extensive use, not just within the Spirit community. I could have easily "fixed" the non-standard type deduction protocol in V2 but decided that breaking the interface should be done with care starting with v3. We value backward compatibility.
It also should have a clearer implementation, even if it may not be as efficient.
clearer implementation? What makes you think so? Because of proto? I don't agree. You can write very clear code with or without proto. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Mathias Gaunard wrote:
Hartmut Kaiser wrote:
The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists!
Just a question, why review v2 and not v3, which addresses some of v2 issues like non-standard type deduction protocol?
Because it's not ready yet V3 is in alpha. V2 OTOH had years of deployment behind it. It's already in extensive use, not just within the Spirit community. I could have easily "fixed" the non-standard type deduction protocol in V2 but decided that breaking the interface should be done with care starting with v3. We value backward compatibility.
For those interested, I've zipped up the Phoenix3 alpha and put it here: http://boost-sandbox.sf.net/libs/phoenix/phoenix3alpha.tar.gz It builds against trunk. It should also build against the current release branch (pre-1.37), but I haven't tested that. I'd like to stress that this implementation of Phoenix is NOT the subject of this review. I'm not putting it in the file vault so as to avoid confusion. I'm only providing it for people who would like to play with a version of Phoenix built on top of Proto, ResultOf and TypeOf.
It also should have a clearer implementation, even if it may not be as efficient.
clearer implementation? What makes you think so? Because of proto? I don't agree. You can write very clear code with or without proto.
Joel has a good point. The v2 implementation of Phoenix is very clean and modular. In fact, the modular design of Phoenix was challenging for Proto, and I'm not yet satisfied with the results. Typically, a DSEL conforms to a grammar that can be stated simply in one place. Phoenix's modularity means that you can include and use only a subset of the library -- a subset that conforms to a simpler grammar. That means that the Phoenix grammar and expression evaluator needs to be distributed, loosely coupled and pluggable. Proto can do this, but it's not pretty. Perhaps there are ways I can extend Proto to better support modular grammars. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
For those interested, I've zipped up the Phoenix3 alpha and put it here:
http://boost-sandbox.sf.net/libs/phoenix/phoenix3alpha.tar.gz
It builds against trunk. It should also build against the current release branch (pre-1.37), but I haven't tested that.
I'd like to stress that this implementation of Phoenix is NOT the subject of this review. I'm not putting it in the file vault so as to avoid confusion. I'm only providing it for people who would like to play with a version of Phoenix built on top of Proto, ResultOf and TypeOf.
Thanks Eric!
It also should have a clearer implementation, even if it may not be as efficient.
clearer implementation? What makes you think so? Because of proto? I don't agree. You can write very clear code with or without proto.
Joel has a good point. The v2 implementation of Phoenix is very clean and modular. In fact, the modular design of Phoenix was challenging for Proto, and I'm not yet satisfied with the results. Typically, a DSEL conforms to a grammar that can be stated simply in one place. Phoenix's modularity means that you can include and use only a subset of the library -- a subset that conforms to a simpler grammar. That means that the Phoenix grammar and expression evaluator needs to be distributed, loosely coupled and pluggable. Proto can do this, but it's not pretty.
Perhaps there are ways I can extend Proto to better support modular grammars.
I'm sure you'll come up with something very elegant. The result of which will have tremendous impact on Spirit2 and Phoenix3. And I can't thank you enough for your amazing work on this. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Because it's not ready yet V3 is in alpha. V2 OTOH had years of deployment behind it. It's already in extensive use, not just within the Spirit community. I could have easily "fixed" the non-standard type deduction protocol in V2 but decided that breaking the interface should be done with care starting with v3. We value backward compatibility.
Isn't the move to first-class Boost citizen a good opportunity to change some parts of the interface, and thus give a new version number?
Mathias Gaunard wrote:
Joel de Guzman wrote:
Because it's not ready yet V3 is in alpha. V2 OTOH had years of deployment behind it. It's already in extensive use, not just within the Spirit community. I could have easily "fixed" the non-standard type deduction protocol in V2 but decided that breaking the interface should be done with care starting with v3. We value backward compatibility.
Isn't the move to first-class Boost citizen a good opportunity to change some parts of the interface, and thus give a new version number?
Indeed. As noted in the review blurb, V3 will be the future of phoenix. The V3 interface will be assumed. The most major interface shifts are: 1) ET engine: Use of Boost.Proto 2) Result type deduction: Use of Boost.Typeof 3) Type deduction protocol: Use of Boost.Resultof As far as the interface goes, we can take all that for granted. We have the proof of concept. Then again, it's always a balance. Eric ported to V3 a week after BoostCon 08, spurred by our discussions at the conference stemming from his port of lambda. IMO, it's too young to be subject to a review. We'll need more time to polish it, test it on existing code, provide backward compatibility to V2, revise the docs to reflect the changes, etc. V2 OTOH, is already being used in production code and has years of maturity behind it. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Hartmut Kaiser a écrit :
Hi all,
The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! Some questions that a very quick look at the doc did not answer (please point me to the right place if such a place exists):
- If this library is accepted, will that make other boost libraries deprecated? (from the introduction, I'm thinking of function, lambda and bind, maybe some others?) - How does this library position itself wrt the upcomming C++0x standard, with native support for lambdas, and standardized support for function or bind? Is it more expressive? -- Loïc
Loïc Joly wrote:
- How does this library position itself wrt the upcomming C++0x standard, with native support for lambdas, and standardized support for function or bind? Is it more expressive?
The C++0x standard only specifies monomorphic lambdas at the moment. So Phoenix is indeed more expressive, since all expressions are polymorphic.
Mathias Gaunard:
Loïc Joly wrote:
- How does this library position itself wrt the upcomming C++0x standard, with native support for lambdas, and standardized support for function or bind? Is it more expressive?
The C++0x standard only specifies monomorphic lambdas at the moment. So Phoenix is indeed more expressive, since all expressions are polymorphic.
Except phoenix::bind, which is monomorphic, for whatever reasons. :-) http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/co...
on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Mathias Gaunard:
Loïc Joly wrote:
- How does this library position itself wrt the upcomming C++0x > standard, with native support for lambdas, and standardized support for > function or bind? Is it more expressive?
The C++0x standard only specifies monomorphic lambdas at the moment. So Phoenix is indeed more expressive, since all expressions are polymorphic.
Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/co...
Hmm, that seems like it will needlessly restrict generic code. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Mathias Gaunard:
Loïc Joly wrote:
- How does this library position itself wrt the upcomming C++0x > standard, with native support for lambdas, and standardized support for > function or bind? Is it more expressive?
The C++0x standard only specifies monomorphic lambdas at the moment. So Phoenix is indeed more expressive, since all expressions are polymorphic. Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/co...
Hmm, that seems like it will needlessly restrict generic code.
Ah that one. I think that needs clarification. The note is wrong and should be corrected. A bound function pointer or member function pointer is only monorphic once bound (of course -- a single function pointer or member function pointer is monomorphic). The same is true with bind and lambda bind. Phoenix bind, like bind and lambda bind is polymorphic at the call site in the sense that it can bind to any function and function pointer and function object (which can be polymorphic). One problem I notice now with the bind documentation of phoenix is that it lacks the function object binding part. Noted for correction. Pardon the confusion. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Mon Sep 22 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
David Abrahams wrote:
on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Mathias Gaunard:
Loïc Joly wrote:
- How does this library position itself wrt the upcomming C++0x > standard, with native support for lambdas, and standardized support for > function or bind? Is it more expressive?
The C++0x standard only specifies monomorphic lambdas at the moment. So Phoenix is indeed more expressive, since all expressions are polymorphic. Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/composite.html#phoenix.composite.bind> Hmm, that seems like it will needlessly restrict generic code.
Ah that one. I think that needs clarification. The note is wrong and should be corrected. A bound function pointer or member function pointer is only monorphic once bound (of course -- a single function pointer or member function pointer is monomorphic). The same is true with bind and lambda bind.
Yeah, but what about a bound polymorphic function object? The doc makes it sound like passing through bind removes that polymorphism.
Phoenix bind, like bind and lambda bind is polymorphic at the call site in the sense that it can bind to any function and function pointer and function object (which can be polymorphic). One problem I notice now with the bind documentation of phoenix is that it lacks the function object binding part.
Noted for correction. Pardon the confusion.
I'm still confused ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Mon Sep 22 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
David Abrahams wrote:
on Mon Sep 22 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Mathias Gaunard:
Loïc Joly wrote:
- How does this library position itself wrt the upcomming C++0x > standard, with native support for lambdas, and standardized support for > function or bind? Is it more expressive?
The C++0x standard only specifies monomorphic lambdas at the moment. So Phoenix is indeed more expressive, since all expressions are polymorphic. Except phoenix::bind, which is monomorphic, for whatever reasons. :-)
http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc/html/phoenix/composite.html#phoenix.composite.bind> Hmm, that seems like it will needlessly restrict generic code. Ah that one. I think that needs clarification. The note is wrong and should be corrected. A bound function pointer or member function pointer is only monorphic once bound (of course -- a single function pointer or member function pointer is monomorphic). The same is true with bind and lambda bind.
Yeah, but what about a bound polymorphic function object? The doc makes it sound like passing through bind removes that polymorphism.
Phoenix bind, like bind and lambda bind is polymorphic at the call site in the sense that it can bind to any function and function pointer and function object (which can be polymorphic). One problem I notice now with the bind documentation of phoenix is that it lacks the function object binding part.
Noted for correction. Pardon the confusion.
I'm still confused ;-)
You can disregard the note. It is a historic artifact from V1 and is not accurate. Phoenix2 *can* bind to polymorphic function objects. Example: struct sqr { template <typename Arg> struct result { typedef Arg type; }; template <typename Arg> Arg operator()(Arg n) const { return n * n; } }; ... BOOST_TEST(bind(sqr(), arg1)(i5) == (i5*i5)); Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Loïc Joly wrote:
Hartmut Kaiser a écrit :
Hi all,
The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! Some questions that a very quick look at the doc did not answer (please point me to the right place if such a place exists):
- If this library is accepted, will that make other boost libraries deprecated? (from the introduction, I'm thinking of function, lambda and bind, maybe some others?)
boost.function: No. phoenix has no such facility. Don't confuse with phoenix.function. boost.bind: No. bind has its place. It's light(er) and is sufficient for many tasks. At the very least we should work towards a unification of the placeholders and interoperability. boost.lambda: Depends. The original plan was for a Lambda/Phoenix merger with Phoenix2 as the basis. Eseentially, it is possible for Phoenix2(3) to be the new Lambda. I outlined a plan sometime ago: >> One of the obstacles towards merger is that Lambda has some >> quirks of its own that makes it difficult to provide full backwards >> compatibility. Eric ported Phoenix 2.0 to proto, making it Phoenix >> 3.0. In the course of the development, Eric and I seem to both >> coming to the conclusion that the best route is to leave the >> Lambda codebase alone and make Phoenix 3.0 the new lambda >> (i.e. lambda 2.0). And, similar to what we did with Spirit2, >> we can have an interim release that bundles both the old lambda >> and the new. With this approach, code that uses Lambda should >> should not do anything special. Users who want to take advantage >> of the features of Lambda-2 (aka Phoenix) can upgrade with some >> minimal code tweaks. If this is an acceptable solution to all >> parties involved (Jaakko?) Yes, Jaakko is in agreement with this approach: Jaakko: > My first reply didn't make it to the list. > Yes, this would be a good arrangement. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser Sent: 22 September 2008 00:58 To: boost@lists.boost.org; boost-users@lists.boost.org; boost-announce@lists.boost.org Cc: 'Spirit General Mailing List' Subject: [boost] [Review] Phoenix review starts today, September 21st The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008,
Phoenix V2 is a very important infrastructure library, IHMO. It has been used for several other library writing efforts already, most notably, Spirit V2.
Please always state in your review, whether you think the library should be accepted as a Boost library!
I vote for acceptance.
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design?
Seems a pity we need languages within languages within languages, but there you go :-( It clearly "does what it says on the tin".
- What is your evaluation of the documentation?
Reads very nicely, with remarkably few typos (a few I noted attached).
- What is your evaluation of the potential usefulness of the library?
Obviously invaluable.
- Did you try to use the library?
No.
- How much effort did you put into your evaluation?
Read the documentation only. And I think I understood enough of it at a first reading to be happy to jump in and try to use it for real - an important facet of a library like this. If the learning curve is too steep, and the hand holds too far apart...
- Are you knowledgeable about the problem domain?
Slightly. One further comment. I understand the dilemmas of evolution and backward compatibility, so that some evolving versions are inevitable. But from a users point of view, it is also very helpful to know which one to choose. As a newbie, it would help to have some guidance when to use Boost.bind, Boost.Lambda, Phoenix V2 or Phoenix V3. If one is starting a new project and can stand some evolution, should one jump straight to Phoenix V3. What are the likely problems in moving from V2 to V3? Could a summary of the key features, pros and cons be added to the documentation? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
Please always state in your review, whether you think the library should be accepted as a Boost library!
I vote for acceptance.
Thank you!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design?
Seems a pity we need languages within languages within languages, but there you go :-(
One that emulates C++ in C++ even! :P Can another language do that?
It clearly "does what it says on the tin".
- What is your evaluation of the documentation?
Reads very nicely, with remarkably few typos (a few I noted attached).
Will appply. Thanks! [snips ...]
One further comment.
I understand the dilemmas of evolution and backward compatibility, so that some evolving versions are inevitable.
But from a users point of view, it is also very helpful to know which one to choose.
As a newbie, it would help to have some guidance when to use Boost.bind, Boost.Lambda, Phoenix V2 or Phoenix V3.
Right. Ok, duly noted. I'll add an "Evolution" section for this.
If one is starting a new project and can stand some evolution, should one jump straight to Phoenix V3.
Yes.
What are the likely problems in moving from V2 to V3?
Some porting will be required. I'll outline all these in the "Evolution" section.
Could a summary of the key features, pros and cons be added to the documentation?
Ok, but to be sure: "pros and cons" compared to what? BLL, V2 and V3? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Sun, Sep 21, 2008 at 7:58 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Hi all,
The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists!
---------------------------------------------------
Of course, it's hard to be subjective reviewing Phoenix, since I'm already a fan, but I'm going to try to approach this as I would any library and pretend like I don't know who the authors are. My review of Phoenix follows. I think Phoenix version 2 should be rejected as a Boost library. Instead, we should focus on version 3, i.e. Phoenix3/Lambda2. Obviously, there's nothing "wrong" with the Phoenix2 design, implementation, documentation, etc. However, I believe Boost users don't appreciably gain anything from a release of version 2 as a top-level Boost library, and I believe a premature release could actually come at a cost to Boost users as well as Boost developers. Accepting Phoenix2 as a Boost library is essentially just a rebranding of the current library included with Boost.Spirit. I don't see how users benefit from that rebranding. Potentially, the rebranding could deteriorate user experience, since Phoenix2 addresses the same problem domain as other Boost libraries and uses similar names (bind, function, _1) but is not compatible or interoperable with its cousins. Worse, it also overlaps/conflicts with the draft C++ standard library, which many users already have access to from their compiler vendors. This confusion is unnecessary and can be avoided by releasing Phoenix3 (which presumably will play nicely with the standard library) as an upgrade to Boost.Lambda. I'll briefly outline some specific technical concerns. I believe lack of support for the TR1 result_of protocol is a showstopper. Introducing yet another return type deduction protocol only makes users' lives more difficult. As has been suggested the old protocol could be removed from version 2 in favor of result_of, but in Phoenix3 this issue is already resolved. So, why not spend time finishing Phoenix3 rather than bringing version 2 into the post-TR1 world? In a similar vein, I think if a library uses placeholders, lazy evaluation, and other bind-like features, then it's important for the library to reconcile its relationship with the forthcoming std::is_placeholder, std::is_bind_expression, std::bind, etc. Why not expend effort getting it right in Phoenix3 rather than modernizing version 2? Giovanni noted version 2's lack of conformance to the standard algorithm concept requirements, namely Assignability. Conformance to the usual FunctionObject concepts also seems like something that should be required of newly accepted Boost FP libraries. Why not spend time insuring that Phoenix3 is conforming rather than retro-fitting version 2?
- What is your evaluation of the design?
If we were evaluating the library eight years ago, I would have no complaints. But we're evaluating it today, so I have to reiterate that lack of interoperability with the draft standard's FP features is an unacceptable design for a contemporary Boost library.
- What is your evaluation of the implementation?
I haven't really looked at the implementation. I'm kind of reluctant to invest too much time reviewing the current version when I know the Proto port is coming, and that seems to be the actual, valuable, long-term implementation. The code under consideration is known/intended to be transitory; what I'm actually looking forward to is the replacement! I mean we can already use Phoenix2 by including boost/spirit/phoenix.hpp. Moving the code to boost/phoenix isn't really a reason to get excited.
- What is your evaluation of the documentation?
The documentation is excellent. I mostly looked at the "starter kit," which is as good of a quick start guide as any I've seen. However, I seem to remember that the old documentation had an excellent introductory chapter that gave a brief overview of FP and touched on the history of Phoenix. I didn't notice that material in the current documentation. If it was removed, it should be brought back!
- What is your evaluation of the potential usefulness of the library?
Phoenix2 is certainly as useful as Boost.Lambda. However, there is some overhead (in man-months, not CPU cycles) in migrating existing Boost.Lambda code to Phoenix2. I suspect that many users will not find a compelling reason to incur that expense. Also, Phoenix2 makes no guarantees as to Boost.Lambda interoperability; i.e. to a new user, version 2 looks and feels like a completely different library with new documentation to read, new corner cases to discover, etc. So, I suspect that many users will not find a compelling reason to "learn" Phoenix2 for new projects when Boost.Lambda suffices. So, why not spend time making the "upgrade" from Boost.Lambda to Lambda2 (a.k.a. Phoenix3) intuitive and painless rather than making Phoenix2 more appealing/useful than Boost.Lambda?
- Did you try to use the library? With what compiler? Did you have any problems?
Yes, I've used Phoenix with several releases of gcc in the past. For the review, I used gcc 4.0. I've never had any problems.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I've been following the review discussion. I've played around with Phoenix at various times, though I'm not sure that you would call my evaluation "in depth."
- Are you knowledgeable about the problem domain?
I have some experience using FP in C++. Finally, I believe that all the comments and discussion during this review period will strengthen Phoenix3 in the long run. And regardless of the final review decision, Phoenix2 will certainly be remembered in history as a widely admired library and a major milestone in the evolution of FP library techniques in C++. Daniel Walker
on Fri Sep 26 2008, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
On Sun, Sep 21, 2008 at 7:58 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Hi all,
The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists!
---------------------------------------------------
Of course, it's hard to be subjective reviewing Phoenix, since I'm already a fan, but I'm going to try to approach this as I would any library and pretend like I don't know who the authors are. My review of Phoenix follows.
Wow, that was a very thoughtfully written review and I look forward to hearing the response. Your arguments are very persuasive, and highlight some of the concerns I've had since learning that the next version of Phoenix is (nearly ready and?) due to be incompatible with this one. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Daniel Walker wrote:
Of course, it's hard to be subjective reviewing Phoenix, since I'm already a fan, but I'm going to try to approach this as I would any library and pretend like I don't know who the authors are. My review of Phoenix follows.
Thank you for your review.
I think Phoenix version 2 should be rejected as a Boost library. Instead, we should focus on version 3, i.e. Phoenix3/Lambda2.
I understand your concerns. Will you change your vote if I say that Phoenix2 will not be repackaged into Boost? The real intent is to have Phoenix3/Lambda2 into Boost, not Phoenix2. I asked for a review to flesh out the few remaining issues and to achieve the goal of having a top-notch library. All the major issues raised thus far are interface related. These can be implemented in a short period of time in Phoenix. They are not major issues in terms of implementation. Phoenix3 is the proof. Fusion is also a proof. Fusion started out without Typeof and Result_of support. Soon thereafter, these were added. Perhaps it was premature to ask for a review, but if you look closely into the Proto port, Phoenix3 *is* Phoenix2 targetting a different back-end (proto, instead of hand-coded). It's not a total rewrite, like say, Spirit2 from Spirit1 or Phoenix2 from Phoenix1. I was confident that, since Phoenix3 is essentially Phoenix2+proto, that it's good enough to ask for a review pending the finalization of Phoenix3. I also thought that it was a good idea to have the review for Phoenix2 for those who have already invested in the library in order to realize a good transition path from the old to the new. And, not to be forgotten, there's also the Lambda Phoenix relationship. I personally would not want to have Phoenix2 as-is into Boost without providing a strategy for a painless transition for old Lambda into the new. The review is a good opportunity for all these matters to be discussed.
Obviously, there's nothing "wrong" with the Phoenix2 design, implementation, documentation, etc. However, I believe Boost users don't appreciably gain anything from a release of version 2 as a top-level Boost library, and I believe a premature release could actually come at a cost to Boost users as well as Boost developers.
There won't be a premature release. Promise. I thought that was clear from the roadmap I sketched. In as much as many (most?) libraries in Boost get conditional aceptance (they get accepted if certain conditions are met), I was hoping it would be the same for Phoenix. I haven't seen a library getting accepted as-is into Boost. Typically, a post review version of a library -- one that addresses the concerns raisied in the review, is crafted before merging into the trunk.
Accepting Phoenix2 as a Boost library is essentially just a rebranding of the current library included with Boost.Spirit. I don't see how
I agree!
users benefit from that rebranding. Potentially, the rebranding could deteriorate user experience, since Phoenix2 addresses the same problem domain as other Boost libraries and uses similar names (bind, function, _1) but is not compatible or interoperable with its cousins. Worse, it also overlaps/conflicts with the draft C++ standard library, which many users already have access to from their compiler vendors. This confusion is unnecessary and can be avoided by releasing Phoenix3 (which presumably will play nicely with the standard library) as an upgrade to Boost.Lambda.
IMO, Phoenix3(alpha) is not enough, even. So far, some issues like the upgrade to Boost.Lambda you mentioned hasn't been addressed yet. Allow me conditional acceptance and all the issues raised will be addressed in Phoenix3.
I'll briefly outline some specific technical concerns.
I believe lack of support for the TR1 result_of protocol is a showstopper. Introducing yet another return type deduction protocol only makes users' lives more difficult. As has been suggested the old protocol could be removed from version 2 in favor of result_of, but in Phoenix3 this issue is already resolved. So, why not spend time finishing Phoenix3 rather than bringing version 2 into the post-TR1 world?
Exactly. No more effort will be put into Phoenix2. Phoenix3 is the future. Let Phoenix2 stand on its merits in terms of design/implementation/ documentation. Phoenix3 is Phoenix2 plus all of the above and will be the post-review implementation.
In a similar vein, I think if a library uses placeholders, lazy evaluation, and other bind-like features, then it's important for the library to reconcile its relationship with the forthcoming std::is_placeholder, std::is_bind_expression, std::bind, etc. Why not expend effort getting it right in Phoenix3 rather than modernizing version 2?
Yes. That's the idea. To put matters into perspective, the features you want is just a fraction of the totality of the whole Phoenix library. It's a promise that all those features you want will be put in place. But, please don't overlook the things that are already in place.
Giovanni noted version 2's lack of conformance to the standard algorithm concept requirements, namely Assignability. Conformance to the usual FunctionObject concepts also seems like something that should be required of newly accepted Boost FP libraries. Why not spend time insuring that Phoenix3 is conforming rather than retro-fitting version 2?
Agreed.
- What is your evaluation of the design?
If we were evaluating the library eight years ago, I would have no complaints. But we're evaluating it today, so I have to reiterate that lack of interoperability with the draft standard's FP features is an unacceptable design for a contemporary Boost library.
Again, agreed.
- What is your evaluation of the implementation?
I haven't really looked at the implementation. I'm kind of reluctant to invest too much time reviewing the current version when I know the Proto port is coming, and that seems to be the actual, valuable, long-term implementation. The code under consideration is known/intended to be transitory; what I'm actually looking forward to is the replacement! I mean we can already use Phoenix2 by including boost/spirit/phoenix.hpp. Moving the code to boost/phoenix isn't really a reason to get excited.
Phoenix3 is essentially Phoenix2 plus proto and some of the features that brings it into the post TR1 world. If it is the implementation you want to evaluate, you can look into either renditions.
- What is your evaluation of the documentation?
The documentation is excellent. I mostly looked at the "starter kit," which is as good of a quick start guide as any I've seen. However, I seem to remember that the old documentation had an excellent introductory chapter that gave a brief overview of FP and touched on the history of Phoenix. I didn't notice that material in the current documentation. If it was removed, it should be brought back!
Hmm. Some people say I'm overly verbose and chatty. I recently tend to snip portions of the documentation because of that. I'll see what I can do. Thanks for the compliment.
- What is your evaluation of the potential usefulness of the library?
Phoenix2 is certainly as useful as Boost.Lambda. However, there is some overhead (in man-months, not CPU cycles) in migrating existing Boost.Lambda code to Phoenix2. I suspect that many users will not find a compelling reason to incur that expense. Also, Phoenix2 makes no guarantees as to Boost.Lambda interoperability; i.e. to a new user, version 2 looks and feels like a completely different library with new documentation to read, new corner cases to discover, etc. So, I suspect that many users will not find a compelling reason to "learn" Phoenix2 for new projects when Boost.Lambda suffices. So, why not spend time making the "upgrade" from Boost.Lambda to Lambda2 (a.k.a. Phoenix3) intuitive and painless rather than making Phoenix2 more appealing/useful than Boost.Lambda?
Yes. That is actually the plan. Obviously, this review will make things a lot clearer. I would definitely want to hear from you what you want to see/expect. All those wishes/wants will be assimilated into Phoenix3/Lambda2.
- Did you try to use the library? With what compiler? Did you have any problems?
Yes, I've used Phoenix with several releases of gcc in the past. For the review, I used gcc 4.0. I've never had any problems.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I've been following the review discussion. I've played around with Phoenix at various times, though I'm not sure that you would call my evaluation "in depth."
- Are you knowledgeable about the problem domain?
I have some experience using FP in C++.
Finally, I believe that all the comments and discussion during this review period will strengthen Phoenix3 in the long run. And regardless of the final review decision, Phoenix2 will certainly be remembered in history as a widely admired library and a major milestone in the evolution of FP library techniques in C++.
Thank you. I'm still hoping that my explanations will make you change your vote to conditional acceptance. I believe that we actually have an edge over other Boost libraries that were conditional accepted because we actually have a proof of the future that addresses the majority of the issues raised. Nevertheless, your review will definitely help in improving the library. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote: <snip>
To echo David - wow, that was some review from Daniel! In response to Joel - Some of your purpose in requesting a review now is certainly being served for me. The discussion provoked is proving hugely useful and informative, not least because the history of Phoenix apparently goes back a long way, and certainly far beyond the point when I started paying attention. So, as a user who is moderately familiar with BLL, but very new to Phoenix, it would seem there is very little merit in investing too much effort becoming familiar with Phoenix, until V3 arrives. A logic that presumably applies to any new user. As a result of reading Daniel's review my appreciation of the overall 'roadmap' has increased significantly. Daniel's review also mentioned a 'chatty', scene setting introductory chapter that used to part of the documentation. I too would like to this restored to the documentation. Thank you Daniel for such an informative review. - Rob.
Robert Jones wrote:
On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote: <snip>
To echo David - wow, that was some review from Daniel!
In response to Joel - Some of your purpose in requesting a review now is certainly being served for me. The discussion provoked is proving hugely useful and informative, not least because the history of Phoenix apparently goes back a long way, and certainly far beyond the point when I started paying attention.
So, as a user who is moderately familiar with BLL, but very new to Phoenix, it would seem there is very little merit in investing too much effort becoming familiar with Phoenix, until V3 arrives. A logic that presumably applies to any new user.
I would urge you otherwise. I did a quick scan of the Phoenix2 docs. I can safely say that the majority of the interface will remain as-is. Most of the changes will be transparent for the user (for instance the use of boost.typeof and boost.result_of will not affect most code). Neither will the use of a common set of placeholders. There are only two parts in the docs where there will be changes to the interface: the Phoenix function and some parts of the extension mechanism. The first is cosmetic. Really, such interface changes are a normal part of transitioning from pre-review to post-review. All libraries assimilated into boost experience the same transition phase. Some more significant. Take Proto for example, which went from V1 to V2 to V3 from pre to post review. While I understand and appreciate the comments raised thus far, I say that the review grossly magnifies these aspects while underrating the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7, Values, References, Arguments, Composites, Lazy Operators, Lazy Statements Construct, New, Delete, Casts, Operator, Statement, Object, Scope, Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the extension mechanism) will have some changes. Please, let's not throw out the baby with the bathwater.
As a result of reading Daniel's review my appreciation of the overall 'roadmap' has increased significantly.
And, let me emphasize it too, if I haven't done so yet. The Roadmap is very important. I certainly hope for more discussion on these topics. Bridging the current and past and the future is one of the prime motivations behind my asking for a review.
Daniel's review also mentioned a 'chatty', scene setting introductory chapter that used to part of the documentation. I too would like to this restored to the documentation.
If you want a chatty scene, I'll give you a chatty scene, but not too much :-). Actually, there's one more facet of the documentation that's missing: a reference section. I also intend to have one for V3. At least for those who dislike verbose text can get straight to the reference. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Sat Sep 27 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
Please, let's not throw out the baby with the bathwater.
Just to be clear, by praising Daniel's review I was not trying to make some kind of weak vote for rejection. Daniel raised some concerns that I also had, but didn't have the time or presence of mind to articulate, and I am very happy with what Joel has written in response so far. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
While I understand and appreciate the comments raised thus far, I say that the review grossly magnifies these aspects while underrating the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7, Values, References, Arguments, Composites, Lazy Operators, Lazy Statements Construct, New, Delete, Casts, Operator, Statement, Object, Scope, Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the extension mechanism) will have some changes.
Please, let's not throw out the baby with the bathwater.
OK, regarding babies in bathwater... :-) Again, throwing Phoenix out of Boost is not the question. All of the existing functionality is currently distributed with Boost.Spirit and will remain so. The issue is where to go next. I don't want to try to parse what's changed between Phoenix2 and Phoenix3, but it's important to identify what's being reviewed. So, just to get a since of the difference, I ran diff -qr on the two versions and found that of 108 files 43 have been removed and 65 modified. To try to get a sense of the impact of the new Proto backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66 files 27 matched, including bind.hpp. We're not undervaluing Phoenix2; no one is tossing out babies, it will remain in Boost.Spirit. We also shouldn't undervalue the changes that bring us to Phoenix3. So, even though they may seem trivial if you are familiar with the code, the changes between Phoenix2 and Phoenix3 are at least pervasive. Reviewing Phoenix2 is not equivalent to reviewing Phoenix3. Daniel Walker
Daniel Walker wrote:
On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
While I understand and appreciate the comments raised thus far, I say that the review grossly magnifies these aspects while underrating the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7, Values, References, Arguments, Composites, Lazy Operators, Lazy Statements Construct, New, Delete, Casts, Operator, Statement, Object, Scope, Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the extension mechanism) will have some changes.
Please, let's not throw out the baby with the bathwater.
OK, regarding babies in bathwater... :-) Again, throwing Phoenix out of Boost is not the question. All of the existing functionality is currently distributed with Boost.Spirit and will remain so. The issue is where to go next.
I don't want to try to parse what's changed between Phoenix2 and Phoenix3, but it's important to identify what's being reviewed. So, just to get a since of the difference, I ran diff -qr on the two versions and found that of 108 files 43 have been removed and 65 modified. To try to get a sense of the impact of the new Proto backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66 files 27 matched, including bind.hpp.
I'm sure most folks here will agree that diffing and grepping files do not do justice in assessing the difference from one revision to the next. Only an in-depth perusal will reveal that the structure and design of V2 is essentially the same as V3. I understand if you don't want to go there. But let me just emphasize my point: the majority of the interface, regardless of implementation, from V2 to V3 will remain stable. To me, that is most important. The interface is the single most crucial factor that took many years to evolve and perfect. The new additions, as pointed out in this review, and as provided by V3, such as support for result_of, use of boost.typeof, compatibility with TR1, etc, are low hanging fruits and IMO, feature per feature, pale in comparison to what's in V2 thus far.
We're not undervaluing Phoenix2; no one is tossing out babies, it will remain in Boost.Spirit. We also shouldn't undervalue the changes that bring us to Phoenix3. So, even though they may seem trivial if you are familiar with the code, the changes between Phoenix2 and Phoenix3 are at least pervasive. Reviewing Phoenix2 is not equivalent to reviewing Phoenix3.
I understand. Thanks for your review. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Sat, Sep 27, 2008 at 8:25 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote:
On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
While I understand and appreciate the comments raised thus far, I say that the review grossly magnifies these aspects while underrating the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7, Values, References, Arguments, Composites, Lazy Operators, Lazy Statements Construct, New, Delete, Casts, Operator, Statement, Object, Scope, Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the extension mechanism) will have some changes.
Please, let's not throw out the baby with the bathwater.
OK, regarding babies in bathwater... :-) Again, throwing Phoenix out of Boost is not the question. All of the existing functionality is currently distributed with Boost.Spirit and will remain so. The issue is where to go next.
I don't want to try to parse what's changed between Phoenix2 and Phoenix3, but it's important to identify what's being reviewed. So, just to get a since of the difference, I ran diff -qr on the two versions and found that of 108 files 43 have been removed and 65 modified. To try to get a sense of the impact of the new Proto backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66 files 27 matched, including bind.hpp.
I'm sure most folks here will agree that diffing and grepping files do not do justice in assessing the difference from one revision to the next. Only an in-depth perusal will reveal that the structure and design of V2 is essentially the same as V3. I understand if you don't want to go there. But let me just emphasize my point: the majority of the interface, regardless of implementation, from V2 to V3 will remain stable. To me, that is most important.
I just mean to show that the two versions are different - not the structure, design or interface, but the implementation, which of course, is also important. Daniel Walker
Daniel Walker wrote:
On Sat, Sep 27, 2008 at 8:25 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote:
On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
While I understand and appreciate the comments raised thus far, I say that the review grossly magnifies these aspects while underrating the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7, Values, References, Arguments, Composites, Lazy Operators, Lazy Statements Construct, New, Delete, Casts, Operator, Statement, Object, Scope, Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the extension mechanism) will have some changes.
Please, let's not throw out the baby with the bathwater. OK, regarding babies in bathwater... :-) Again, throwing Phoenix out of Boost is not the question. All of the existing functionality is currently distributed with Boost.Spirit and will remain so. The issue is where to go next.
I don't want to try to parse what's changed between Phoenix2 and Phoenix3, but it's important to identify what's being reviewed. So, just to get a since of the difference, I ran diff -qr on the two versions and found that of 108 files 43 have been removed and 65 modified. To try to get a sense of the impact of the new Proto backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66 files 27 matched, including bind.hpp. I'm sure most folks here will agree that diffing and grepping files do not do justice in assessing the difference from one revision to the next. Only an in-depth perusal will reveal that the structure and design of V2 is essentially the same as V3. I understand if you don't want to go there. But let me just emphasize my point: the majority of the interface, regardless of implementation, from V2 to V3 will remain stable. To me, that is most important.
I just mean to show that the two versions are different - not the structure, design or interface, but the implementation, which of course, is also important.
Agreed. The implementation is also *very* important. Is it safe to say at least that grepping and diffing cannot be considered to be an in-depth analysis of the implementation? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Sat, Sep 27, 2008 at 9:53 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote:
On Sat, Sep 27, 2008 at 8:25 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote:
On Sat, Sep 27, 2008 at 7:39 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
While I understand and appreciate the comments raised thus far, I say that the review grossly magnifies these aspects while underrating the remaining 95% of the library. If you look at: http://tinyurl.com/4y47z7, Values, References, Arguments, Composites, Lazy Operators, Lazy Statements Construct, New, Delete, Casts, Operator, Statement, Object, Scope, Bind will remain as-is. Only Lazy Functions and Inside Phoenix (the extension mechanism) will have some changes.
Please, let's not throw out the baby with the bathwater.
OK, regarding babies in bathwater... :-) Again, throwing Phoenix out of Boost is not the question. All of the existing functionality is currently distributed with Boost.Spirit and will remain so. The issue is where to go next.
I don't want to try to parse what's changed between Phoenix2 and Phoenix3, but it's important to identify what's being reviewed. So, just to get a since of the difference, I ran diff -qr on the two versions and found that of 108 files 43 have been removed and 65 modified. To try to get a sense of the impact of the new Proto backend, I ran grep -rle 'proto::' on Phoenix3 and found that of 66 files 27 matched, including bind.hpp.
I'm sure most folks here will agree that diffing and grepping files do not do justice in assessing the difference from one revision to the next. Only an in-depth perusal will reveal that the structure and design of V2 is essentially the same as V3. I understand if you don't want to go there. But let me just emphasize my point: the majority of the interface, regardless of implementation, from V2 to V3 will remain stable. To me, that is most important.
I just mean to show that the two versions are different - not the structure, design or interface, but the implementation, which of course, is also important.
Agreed. The implementation is also *very* important. Is it safe to say at least that grepping and diffing cannot be considered to be an in-depth analysis of the implementation?
Of course not. :-) But going in-depth into V2's implementation is not the same as going in-depth into V3. The design may be the same, but simple diffing and greping shows the implementations are not. And that's to be expected. As I understand, whole components were gutted and replaced with Proto, which is a good thing. So let's continue that effort and spend our energy on V3 and not look back! Now, how that relates to the review formalities and the fact that apparently V2 is under review, I am not sure. As far as I can tell, all the reviews thus far have assumed the V2 implementation. I would suggest withdrawing V2 from consideration (leaving it as is in Boost.Spirit), finishing V3 (which becomes the new Boost.Lambda), and then resubmitting for review, but I'm no expert on this process. Obviously, we don't want to find ourselves in a situation where we review a library that will never be released (V2) and then release a library that has never been reviewed (V3). So, as long as we avoid that awful end, I think everything will be fine. Of course, I'm also just happy to see the ball rolling! ;-) Daniel Walker
On Sat, Sep 27, 2008 at 11:31 AM, Robert Jones <robertgbjones@gmail.com> wrote:
On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote: <snip>
To echo David - wow, that was some review from Daniel!
I should perhaps have been clear - my vote to accept Phoenix still stands. There's just too much good stuff in it to turn it down! - Rob.
On Sat, Sep 27, 2008 at 3:39 PM, Robert Jones <robertgbjones@gmail.com> wrote:
On Sat, Sep 27, 2008 at 11:31 AM, Robert Jones <robertgbjones@gmail.com> wrote:
On Sat, Sep 27, 2008 at 4:44 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote: <snip>
To echo David - wow, that was some review from Daniel!
I should perhaps have been clear - my vote to accept Phoenix still stands.
There's just too much good stuff in it to turn it down!
Thanks for the pats-on-the-back! And of course, I'm not lobbying to change anyone's vote. There are lots of valid reasons to vote for acceptance. Also, just to clarify, none of the good stuff in Phoenix2 will be turned down as a result of this review. Phoenix is currently distributed with Boost.Spirit and that should definitely remain the case. So, voting no does not mean removing Phoenix from Boost. What's at issue is whether/how Phoenix should be distributed as a top-level, Boost-reviewed library. IMHO, I think Phoenix should be distributed as a major upgrade of Boost.Lambda. Voting yes, as far as I can tell, means distributing Phoenix2 as it's own top-level library - Boost.Phoenix - at least for some period of time, which I don't agree with. But then perhaps there is some confusion as to what exactly is being reviewed. Daniel Walker
Joel de Guzman wrote:
And, not to be forgotten, there's also the Lambda Phoenix relationship. I personally would not want to have Phoenix2 as-is into Boost without providing a strategy for a painless transition for old Lambda into the new. The review is a good opportunity for all these matters to be discussed.
I suppose adding support for the sig template in boost::result_of would surely be of use. I remember a technique to detect template members was discussed, so it ought to be possible. Also, when using decltype or emulation, there should be no problem, since the return type deduction technique isn't used at all. On a related note, I think compatibility with the result_type protocol is also very important, since it is still what the standard library uses. (I don't know if it's ever planned that it will use result_of instead, but for the moment my standard library -- latest GCC -- requires result_type on its function objects fairly often). So as I said in another thread, phoenix should try to provide result_type whenever possible. A simple make_monorphic<T1, ..., Tn>(f) helper could also be useful (it would simply invocate result_of with the template arguments to generate the result_type). Also, monomorphic function objects should be able to lead to even clearer error messages, so it could be interesting from that point of view too. Ideally, it would be nice if the signatures of the generated objects were as restricted as possible, in a similar way to inference in ML. (one could think of using SFINAE to check the arguments have all the necessary proprieties for the function call -- but I wouldn't require that of Phoenix)
Mathias Gaunard wrote:
Joel de Guzman wrote:
And, not to be forgotten, there's also the Lambda Phoenix relationship. I personally would not want to have Phoenix2 as-is into Boost without providing a strategy for a painless transition for old Lambda into the new. The review is a good opportunity for all these matters to be discussed.
I suppose adding support for the sig template in boost::result_of would surely be of use. I remember a technique to detect template members was discussed, so it ought to be possible.
Also, when using decltype or emulation, there should be no problem, since the return type deduction technique isn't used at all.
On a related note, I think compatibility with the result_type protocol is also very important, since it is still what the standard library uses. (I don't know if it's ever planned that it will use result_of instead, but for the moment my standard library -- latest GCC -- requires result_type on its function objects fairly often).
AFAIR, the old standard library result_type protocol is compatible with the result_of protocol.
So as I said in another thread, phoenix should try to provide result_type whenever possible. A simple make_monorphic<T1, ..., Tn>(f) helper could also be useful (it would simply invocate result_of with the template arguments to generate the result_type).
Ok. Let's see how it goes. Good suggestion.
Also, monomorphic function objects should be able to lead to even clearer error messages, so it could be interesting from that point of view too. Ideally, it would be nice if the signatures of the generated objects were as restricted as possible, in a similar way to inference in ML. (one could think of using SFINAE to check the arguments have all the necessary proprieties for the function call -- but I wouldn't require that of Phoenix)
These are all very good comments and suggestions. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
AFAIR, the old standard library result_type protocol is compatible with the result_of protocol.
std::result_of<F(the args types)> uses F::result_type if it exists, but the other way around is of course not possible, since result_type can only work with monomorphic functors. So if I have a function that expects a functor F that provides F::result_type, the fact that the functor provides std::result_of<F(the args types)>::type, doesn't really help since it doesn't guarantee F::result_type is available.
On Fri, Sep 26, 2008 at 11:44 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Daniel Walker wrote:
I think Phoenix version 2 should be rejected as a Boost library. Instead, we should focus on version 3, i.e. Phoenix3/Lambda2.
I understand your concerns.
Will you change your vote if I say that Phoenix2 will not be repackaged into Boost? The real intent is to have Phoenix3/Lambda2 into Boost, not Phoenix2.
Then let's review Phoenix3/Lambda2. I might vote yes for that library after I have a chance to review it. I can't vote yes for Phoenix2; i.e. the library linked to by the review manager at the beginning of this thread. In other words, I can't accept the library I have reviewed, not without major changes: 1) The documentation is great for Phoenix2. But it is not the documentation for Lambda2. It will need to be significantly rewritten. As I believe you mentioned earlier, the Lambda2 documentation should probably include a lot of material from the current Boost.Lambda documentation that folks are familiar with. 2) The implementation needs significant changes to replace the "backend" with Proto. Apparently, that work is just about complete in Phoenix3 alpha. So again, why shouldn't we spend time on the library implementation we actually intended to distribute? There has been a conflicting argument put forward in the discussion so far. Phoenix2 is mature and already distributed, so we can be confident in it's implementation. But the implementation we actually want is Phoenix3, which is not widely used or mature or even complete. 3) The interface also needs several change in order to be a drop-in replacement for Boost.Lambda. As far as I understand, we're just beginning to consider what these changes may be: What should be decremented in the old Lambda and relegated to a backwards compatibility mode in favor of new Phoenix-like constructs, what should be the default interface when Lambda and Phoenix differ, etc.? There also needs to be several interface changes in order for Phoenix3/Lambda2 to be complementary to and/or compatible with the draft standard library. Also, the final interface will be "incompatible" with Phoenix2, at least in so far as the namespace will be boost::lambda instead of boost::phoenix, but I believe a number of other changes have been mentioned here as well. <snip>
- What is your evaluation of the implementation?
I haven't really looked at the implementation. I'm kind of reluctant to invest too much time reviewing the current version when I know the Proto port is coming, and that seems to be the actual, valuable, long-term implementation. The code under consideration is known/intended to be transitory; what I'm actually looking forward to is the replacement! I mean we can already use Phoenix2 by including boost/spirit/phoenix.hpp. Moving the code to boost/phoenix isn't really a reason to get excited.
Phoenix3 is essentially Phoenix2 plus proto and some of the features that brings it into the post TR1 world. If it is the implementation you want to evaluate, you can look into either renditions.
Thanks for all your responses, but I believe this comment gets to the crux of my vote, so I'll just cut to the chase. I understand that libraries change during the review process. Also, sometimes libraries are revised and submitted for a second review as was the case with Boost.Serialization. However, what are we supposed to be reviewing? The code linked to by the review manager? Phoenix3 alpha? Something else? If you feel that the review process will help in completing Phoenix3, that's fine. However, I can't vote for conditional acceptance when the condition is something like "replace Boost.Lambda." Upgrading this central library will be a major change for the entire Boost community... a much needed change, as well! And I'm looking forward to it, but Phoenix2 is not there yet, and as far as I can tell, Phoenix3 is not being reviewed. Maybe we just have different understandings of what a review is supposed to be. I'm not sure that it actually matters; it's kind of a formality. I'm more interested in getting into some of the nitty gritty problems related to the actual release of Phoenix as Lambda2. That's the fun part! ;-) It's just that in my mind, on the development road map, the Boost-reviewed stamp of approval should be applied at the end of the road rather than in the middle. Daniel Walker
Joel de Guzman wrote:
Daniel Walker wrote:
- What is your evaluation of the documentation?
The documentation is excellent. I mostly looked at the "starter kit," which is as good of a quick start guide as any I've seen. However, I seem to remember that the old documentation had an excellent introductory chapter that gave a brief overview of FP and touched on the history of Phoenix. I didn't notice that material in the current documentation. If it was removed, it should be brought back!
Hmm. Some people say I'm overly verbose and chatty. I recently tend to snip portions of the documentation because of that. I'll see what I can do. Thanks for the compliment.
I agree with Daniel, an FP overview would be very useful, especially since you already have the info written. And please do keep up the verbosity. :-) I had always avoided parsing projects until I read through your Spirit docs. The background info on general parsing gave me what I needed to quickly use spirit, and since then I've been looking for any chance to use spirit. Jeff
Hartmut Kaiser wrote:
Hi all,
Please always state in your review, whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain?
Regards Hartmut Review Manager
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I vote to accept Phoenix. The only comments I have beyond the issues discussed by others: - it would be nice to document which headers are required for the different types and facilities. Or did I miss this somewhere, the only #includes I remember were under the Constant References and Nothing headings - comparison of compiler performance between BLL, Bind... (BLL compile times have a bad rap with my colleagues) - discussion/example using with boost::function, boost::ref/cref,... As others have mentioned, I'd like to see _1, _2, ... rather than the arg1, arg2... ala boost bind and reintroduce the FP background section in the docs. I'm thinking the construct and new_ lazy functions will be particularly useful. Many of our classes end up in containers and or as output from transformed ranges, and end up with many bound static make functions replicating the constructor arguments. Phoenix "construct" makes all those "make"'s redundant. :) Would it be generally useful to have a variant of "new_" that returns a shared_ptr directly? Without it one would need: construct< shared_ptr<X> >( new_<X>( _1, 123, "another arg" ) ) maybe a second template parameter to new_ would allow: new_<X, shared_ptr>(...)? Jeff Flinn
On Wed, Oct 1, 2008 at 3:17 PM, Jeff Flinn <TriumphSprint2000@hotmail.com>wrote:
I'm thinking the construct and new_ lazy functions will be particularly useful. Many of our classes end up in containers and or as output from transformed ranges, and end up with many bound static make functions replicating the constructor arguments. Phoenix "construct" makes all those "make"'s redundant. :)
I think, too, that those lazy functions would be very useful, and I look forward some way to express also placement new. Ideally, I would like to delay which version of new is called to the call site, so I would need a new2_ lazy function such that 'new2_<T>( _1 ) (x)' is still a functor with overloaded operator (), that can be called with 0 arguments (normal new behaviour), and with 1 argument (placement new), ... Would it be generally useful to have a variant of "new_" that returns a
shared_ptr directly? Without it one would need:
Yes, I think this will be very useful. Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo@gmail.com PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------
Corrado Zoccolo wrote:
On Wed, Oct 1, 2008 at 3:17 PM, Jeff Flinn <TriumphSprint2000@hotmail.com>wrote:
I'm thinking the construct and new_ lazy functions will be particularly useful. Many of our classes end up in containers and or as output from transformed ranges, and end up with many bound static make functions replicating the constructor arguments. Phoenix "construct" makes all those "make"'s redundant. :)
I think, too, that those lazy functions would be very useful, and I look forward some way to express also placement new. Ideally, I would like to delay which version of new is called to the call site, so I would need a new2_ lazy function such that 'new2_<T>( _1 ) (x)' is still a functor with overloaded operator (), that can be called with 0 arguments (normal new behaviour), and with 1 argument (placement new), ...
Would it be generally useful to have a variant of "new_" that returns a
shared_ptr directly? Without it one would need:
Yes, I think this will be very useful.
Yes, and yes! :-) Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
participants (12)
-
Corrado Zoccolo -
Daniel Walker -
David Abrahams -
Eric Niebler -
Hartmut Kaiser -
Jeff Flinn -
Joel de Guzman -
Loïc Joly -
Mathias Gaunard -
Paul A Bristow -
Peter Dimov -
Robert Jones