[Review] Phoenix V3: Mini-review starts February 20th
Hi all, Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library. This mini-review starts today, February 20th, 2011 and ends on March 2nd, 2011. ------------------ 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. Phoenix is a very important infrastructure library. It is currently a utility library included with Spirit V2 and therefore is already available for years 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_45_0/libs/spirit/phoenix/index.html) ------------------ The code of new Phoenix V3 (that's what we mini-review) can be found at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/ the documentation is at: http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht ml/index.html ------------------ Here are the questions raised during the initial review of Phoenix in September 2008 (see here: http://thread.gmane.org/gmane.comp.lib.boost.devel/180753): <quote> We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times </quote> Please note that Phoenix already has been accepted as a Boost library. We don't vote about that anymore. The purpose of this mini-review is to discuss if the newly rewritten Phoenix V3 addresses the outstanding issues from the main review. In the end I will have to make the decision whether to include the new library into SVN trunk. I really hope to see your participation in the discussions on the Boost mailing lists! Regards Hartmut Review Manager --------------- http://boost-spirit.com
Hi Hartmut, On Mon, Feb 21, 2011 at 9:32 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com>wrote:
Hi all,
The code of new Phoenix V3 (that's what we mini-review) can be found at:
The source code works with Boost 1.45 or with the Trunk? Thank you very much, Fernando.
On Mon, Feb 21, 2011 at 8:51 PM, Fernando Pelliccioni <fpelliccioni@gmail.com> wrote:
Hi Hartmut,
On Mon, Feb 21, 2011 at 9:32 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Hi all,
The code of new Phoenix V3 (that's what we mini-review) can be found at:
The source code works with Boost 1.45 or with the Trunk?
Sorry, I forgot to mention, the source code only works with the Trunk.
Thank you very much, Fernando.
Hi Thomas, The source file "phoenix/core/terminal.hpp" contains ... #include <boost/phoenix/core/as_actor.hpp> I don't have "as_actor.hpp" file. I am using: MSVC 2008 Phoenix V3 revision: 69191 Boost-trunk revision: 69191 I am trying to compile the "container_actor.cpp" file in example folder. Compiling... container_actor.cpp c:\program files\boost\boost-trunk\boost\phoenix\core\terminal.hpp(14) : fatal error C1083: Cannot open include file: 'boost/phoenix/core/as_actor.hpp': No such file or directory define_expression.cpp c:\program files\boost\boost-trunk\boost\phoenix\core\terminal.hpp(14) : fatal error C1083: Cannot open include file: 'boost/phoenix/core/as_actor.hpp': No such file or directory Regards, Fernando Pelliccioni.
On Wed, Feb 23, 2011 at 12:42 AM, Fernando Pelliccioni <fpelliccioni@gmail.com> wrote:
Hi Thomas, The source file "phoenix/core/terminal.hpp" contains ...
#include <boost/phoenix/core/as_actor.hpp>
Fixed, sorry for the inconvenience.
I don't have "as_actor.hpp" file. I am using:
MSVC 2008 Phoenix V3 revision: 69191 Boost-trunk revision: 69191
I am trying to compile the "container_actor.cpp" file in example folder.
Compiling... container_actor.cpp c:\program files\boost\boost-trunk\boost\phoenix\core\terminal.hpp(14) : fatal error C1083: Cannot open include file: 'boost/phoenix/core/as_actor.hpp': No such file or directory define_expression.cpp c:\program files\boost\boost-trunk\boost\phoenix\core\terminal.hpp(14) : fatal error C1083: Cannot open include file: 'boost/phoenix/core/as_actor.hpp': No such file or directory
Regards, Fernando Pelliccioni.
Hi Thomas, "as_actor.hpp" is also included in "\phoenix\core\value.hpp" Sorry for not having noticed before! :( Regards, Fernando. On Tue, Feb 22, 2011 at 9:24 PM, Thomas Heller <thom.heller@googlemail.com>wrote:
On Wed, Feb 23, 2011 at 12:42 AM, Fernando Pelliccioni <fpelliccioni@gmail.com> wrote:
Hi Thomas, The source file "phoenix/core/terminal.hpp" contains ...
#include <boost/phoenix/core/as_actor.hpp>
Fixed, sorry for the inconvenience.
I don't have "as_actor.hpp" file. I am using:
MSVC 2008 Phoenix V3 revision: 69191 Boost-trunk revision: 69191
I am trying to compile the "container_actor.cpp" file in example folder.
Compiling... container_actor.cpp c:\program files\boost\boost-trunk\boost\phoenix\core\terminal.hpp(14) : fatal error C1083: Cannot open include file: 'boost/phoenix/core/as_actor.hpp': No such file or directory define_expression.cpp c:\program files\boost\boost-trunk\boost\phoenix\core\terminal.hpp(14) : fatal error C1083: Cannot open include file: 'boost/phoenix/core/as_actor.hpp': No such file or directory
Regards, Fernando Pelliccioni.
On Monday, February 21, 2011 08:51:37 PM Fernando Pelliccioni wrote:
Hi Hartmut,
On Mon, Feb 21, 2011 at 9:32 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com>wrote:
Hi all,
The code of new Phoenix V3 (that's what we mini-review) can be found at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/
The source code works with Boost 1.45 or with the Trunk?
One little addition: Phoenix V3 also works with Boost 1.46.
Thank you very much, Fernando.
On Mon, Feb 21, 2011 at 9:32 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com>wrote:
Hi all,
Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library.
This mini-review starts today, February 20th, 2011 and ends on March 2nd, 2011.
I really hope to see your participation in the discussions on the Boost mailing lists!
Regards Hartmut Review Manager
Hi, I am making a comparison between PhoenixV2 and PhoenixV3 documentation to realize what features were added. Is there a "What's new" page to indicate these differences? On the other hand, I read some comments in the Boost mailing list about the possibility of Lisp Macro Capability using PhoenixV3. Are there examples and documentation of this? Thank you all for your excellent work! Regards, Fernando Pelliccioni.
On Wednesday, February 23, 2011 04:33:54 PM Fernando Pelliccioni wrote:
On Mon, Feb 21, 2011 at 9:32 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com>wrote:
Hi all,
Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library.
This mini-review starts today, February 20th, 2011 and ends on March 2nd, 2011.
I really hope to see your participation in the discussions on the Boost mailing lists!
Regards Hartmut Review Manager
Hi,
I am making a comparison between PhoenixV2 and PhoenixV3 documentation to realize what features were added. Is there a "What's new" page to indicate these differences?
No there is no such page, unfortunately. The "front-end" was unchanged, except that boost::function uses the result_of (1) protocol. Other changes are mostly in the backend, due to the port to Boost.Proto the almost everything behind the scenes changed. I tried to document that in the "Inside Phoenix" section in the documentation. This includes the extension mechanisms (meta_grammar, and Actions).
On the other hand, I read some comments in the Boost mailing list about the possibility of Lisp Macro Capability using PhoenixV3. Are there examples and documentation of this?
Not yet, I will deliver one ASAP.
Thank you all for your excellent work!
Regards, Fernando Pelliccioni. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wednesday, February 23, 2011 04:47:01 PM Thomas Heller wrote: <snip>
No there is no such page, unfortunately. The "front-end" was unchanged, except that boost::function uses the result_of (1) protocol.
phoenix::function of course. <snip>
On Wed, Feb 23, 2011 at 1:01 PM, Thomas Heller <thom.heller@googlemail.com>wrote:
On Wednesday, February 23, 2011 04:47:01 PM Thomas Heller wrote: <snip>
No there is no such page, unfortunately. The "front-end" was unchanged, except that boost::function uses the result_of (1) protocol.
phoenix::function of course.
<snip>
Sure, I saw that in the doc... :) I am eager to use the "Lisp Macros". Thanks and regards, Fernando.
On Wednesday, February 23, 2011 05:43:18 PM you wrote:
On Wed, Feb 23, 2011 at 1:01 PM, Thomas Heller
<thom.heller@googlemail.com>wrote:
On Wednesday, February 23, 2011 04:47:01 PM Thomas Heller wrote: <snip>
No there is no such page, unfortunately. The "front-end" was unchanged, except that boost::function uses the result_of (1) protocol.
phoenix::function of course.
<snip>
Sure, I saw that in the doc... :)
I am eager to use the "Lisp Macros".
Alrighty then: http://goo.gl/YVU5L Have fun :)
Thanks and regards, Fernando.
Hartmut Kaiser wrote:
Hi all,
Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library.
Hello, As the documentation don't states explicitly what has been changed, could you give the links where we can find how the issues - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times have been addressed without taking too much time? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Phoenix-V3-Mini-review-starts-Febr... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Saturday, February 26, 2011 08:59:06 AM Vicente Botet wrote:
Hartmut Kaiser wrote:
Hi all,
Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library.
Hello,
As the documentation don't states explicitly what has been changed, could you give the links where we can find how the issues
- the breaking interface changes from v2 The result_of protocol. Apart from phoenix::function, the frontend API didn't change, phoenix::function now only recognizes Function objects conforming to the result_of protocol.
- the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) The interoperability is fully given, all tests from the bind testsuite pass.
- C++0x features such as rvalue references and variadic templates None of these techniques were implemented.
- the new extensibility mechanism This is documented.
- unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) Unified palceholders are documented. Interoperability with other Proto-based DSELs comes naturally with the use of proto.
- compile times This is probably the weakest part of Phoenix V3 at the moment. Compile times are slightly higher than with Phoenix V2. Keep in mind though, that Phoenix V3 is, due to proto, able to do more. More features come at a price.
have been addressed without taking too much time?
Hope that helps!
Thanks, Vicente
Thomas Heller-7 wrote:
On Saturday, February 26, 2011 08:59:06 AM Vicente Botet wrote:
Hartmut Kaiser wrote:
Hi all,
Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library.
Hello,
As the documentation don't states explicitly what has been changed, could you give the links where we can find how the issues
- the breaking interface changes from v2 The result_of protocol. Apart from phoenix::function, the frontend API didn't change, phoenix::function now only recognizes Function objects conforming to the result_of protocol.
- the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) The interoperability is fully given, all tests from the bind testsuite pass.
- C++0x features such as rvalue references and variadic templates None of these techniques were implemented.
- the new extensibility mechanism This is documented.
- unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) Unified palceholders are documented. Interoperability with other Proto-based DSELs comes naturally with the use of proto.
- compile times This is probably the weakest part of Phoenix V3 at the moment. Compile times are slightly higher than with Phoenix V2. Keep in mind though, that Phoenix V3 is, due to proto, able to do more. More features come at a price.
have been addressed without taking too much time?
Hope that helps!
Yes it helps, but what I was requesting for was if you could, please, give the links to the documentation where all these points are documented, so people will loss less time reviewing the documentation? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Phoenix-V3-Mini-review-starts-Febr... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Saturday, February 26, 2011 02:36:02 PM Vicente Botet wrote:
Thomas Heller-7 wrote:
On Saturday, February 26, 2011 08:59:06 AM Vicente Botet wrote:
Hartmut Kaiser wrote:
Hi all,
Thomas Heller worked hard to address the outstanding issues of the original Phoenix review. He ported Phoenix to Boost.Proto. As mandated by the original Boost review, we will conduct a mini-review of his Phoenix V3 library.
Hello,
As the documentation don't states explicitly what has been changed, could you give the links where we can find how the issues
- the breaking interface changes from v2
The result_of protocol. Apart from phoenix::function, the frontend API didn't change, phoenix::function now only recognizes Function objects conforming to the result_of protocol.
The change is not documented anywhere specifically, but phoenix::function is documented here: http://goo.gl/u6mUk
- the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics)
The interoperability is fully given, all tests from the bind testsuite pass.
Is mentioned here: http://goo.gl/WH5vy
- C++0x features such as rvalue references and variadic templates
None of these techniques were implemented.
- the new extensibility mechanism
This is documented.
See: http://goo.gl/uCJuv
- unified placeholders and interoperability issues with other Proto-based
DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive)
Unified palceholders are documented. Interoperability with other Proto-based DSELs comes naturally with the use of proto.
Unified placeholders: http://goo.gl/opzHj The interoperability is currently not documented anywhere ... I still have to figure that one out myself ... It is possible though, but probably is more proto related ... maybe Eric can say something about that.
- compile times
This is probably the weakest part of Phoenix V3 at the moment. Compile times are slightly higher than with Phoenix V2. Keep in mind though, that Phoenix V3 is, due to proto, able to do more. More features come at a price.
Yeah, for compiles, get bigger machines and you won't notice them ;)
have been addressed without taking too much time?
Hope that helps!
Yes it helps, but what I was requesting for was if you could, please, give the links to the documentation where all these points are documented, so people will loss less time reviewing the documentation?
Thanks, Vicente
participants (4)
-
Fernando Pelliccioni -
Hartmut Kaiser -
Thomas Heller -
Vicente Botet