[Phoenix] review reminder

Hartmut Kaiser

29 Sep 2008 29 Sep '08

12:16 p.m.

All, this is just a gentle reminder for all of you willing and planning to write a review for Joel de Guzman's and Dan Marsden's library Phoenix V2. The review ends tomorrow, September 30th. If you are for some reason not able to write the review before tomorrow night, please get in contact with me directly, so we can work something out. Regards Hartmut Review Manager

Show replies by date

Robert Ramey

29 Sep 29 Sep

5:24 p.m.

I spent some time looking at this library. I'm looking at the documentation in release 1.36 for phoenix in the spirit library documentation. Here are a few observations: I don't really know enough about functional programming in order to write a revew. My perspective is of someone who is interested in this subject and wants to use phoenix as a vehicule to learn more about it and experiment with it to see to what extent it can help me with the programming problems that I come upon in my daily work. I don't like the current trend in assigning "cute" names to libraries. E.G. spirit, phoenix, proto, xpressive, oven, - I'm sure there are others. The universe libraries is sufficiently large that given a problem, I'm included to scan a list of library names and drill down into those whose names suggest they might help on my current problem. These names don't help me with that. I don't expect anyone to change a current name, and It's not a huge issue - but it is a minor annoyance. When I perused the library documentation, I was left with the idea that I had a general understanding of what it does and that I could make use of it should I decide to. This struck a very positive note for me. However, I would much like to see a few simple examples of complete applications which show how the library can actually shorten/and/or improve the final result. The "First Practical Example" is too trivial and it seems to be the only real example. After writing the above, I looked up the references cited in the documentation. I found that I had the same complaint about most of them. The John Hughes paper (1989!) did have some interesting examples. Maybe implementing the newton-raphson method on in terms of phoenix might have helped me. Robert Ramey

Zeljko Vrba

5:22 p.m.

-cut- Sorry for the reply to the wrong person, but I've deleted the original call for reviews. I used Phoenix 1 two years ago, while Phoenix 2 was still in its infancy. (I also tested the development version of Phoenix 2 at that time, but it was too unstable to be useful.) Being acquainted with functional programming (I have some experience with SML and Ocaml), I can nothing but praise the documentation -- everything needed to use the library is presented clearly and (mostly) in logical order. For people not acquainted with FP, it might be better to put the "Basics" chapter before "Starter Kit", because the "Basics" chapter explains the basic concepts and motivates partial function application and lazy evaluation. I unsuccessfully [*] tried to use Phoenix 2; but if it is as good as Phoenix 1, it is a great and useful library (I particularly like the "argN" placeholders instead of _N from BLL). I certainly like the concepts it is built on. The downside of Phoenix is its interaction (or lack of) with Boost.Lambda. A while back it has been my main source of confusion -- should I use BLL which _seems_ less powerful; or at least harder to extend [I really like the polymorphic function concept in Phoenix]), or Phoenix? Reading about the possibility of unification of BLL and Phoenix (on various mailing lists), but without any concrete hints on whether cooperation of Jaako and Joel has begun or not, does not help to resolve that confusion. Personally, if my compiler supported the Phoenix library, I'd start using it immediately. The thing that tips me over in favor of Phoenix 2 the most is its transparent, logical and well-organized documentation and greater generality over BLL. Phoenix2 manipulates polymorphic function objects and it is impressive to see in the documentation the implementation of the lazy while_ statement. Thus, BLL looks like just a special case of Phoenix2. To avert the confusion, it might help to put in the documentation a table explaining the main differences between BLL and Phoenix2. [*] Now, the bad thing: my main development platform is Solaris with SunCC, version CC: Sun C++ 5.9 SunOS_i386 Patch 124864-07 2008/08/22 I tried to compile libs/spirit/phoenix/example/users_manual/all_odds.cpp and it fails with many messages like: "/home/zvrba/COMPILE/boost_1_36_0/boost/preprocessor/slot/detail/shared.hpp", line 27: Error: Badly formed constant expression. where the offending line(s) are of the form # if (BOOST_PP_VALUE) / 1000000000UL == 0 (it seems that the preprocessor doesn't like the UL suffix). Funnily enough, some programs from the tests/ directory compile and work OK. That said, I'd recommend that Phoenix2 is accepted into Boost. The main objection is the lack of description of its relation to BLL, as well as some hints of future directions. In the long run, I don't think that it is good to have two overlapping, if not even competing, libraries. My personal preference goes clearly in favor of Phoenix 2, even though it does not work on the platform where I'd like to use it (whereas BLL does work). On Mon, Sep 29, 2008 at 09:24:54AM -0800, Robert Ramey wrote:

...

I spent some time looking at this library. I'm looking at the documentation in release 1.36 for phoenix in the spirit library documentation.

Roland Bock

8:04 p.m.

Hi, a few thoughts: Name: ====== Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it. It also helps the library's developers and contributors to focus. With a name like Phoenix, the sky is the limit. Remember the time when Firefox aka Mozilla was called Phoenix? The same is true for Spirit. If nobody had told me to use Spirit for parsing, I probably would never have come to use it. And looking at Spirit, I was quite astonished to find the Phoenix things in there. To me Spirit looked like small collection of libraries inside a bigger collection of libraries (boost). I bet that there would have been quite a different development with a different, more focused name. The name "Phoenix" does neither help to find the library nor does it help to decide whether to have a certain feature included or not. Want MPL inside Phoenix? Er, well, yes, why not? Want Graph functionality? Yeah, would be great to be able to draw up relationships between Phoenix actors. Sorry, I might be exaggerating... Phoenix: ======== Now Phoenix is about to be taken out of Spirit which is good for both Spirit and Phoenix, I guess. From what I have read so far, Phoenix seems to have very powerful features. It deserves to live outside Spirit. But many of Phoenix' features seem to be variants (improved, probably) of exisiting things like bind, lambda, ref, functional. I consider this a problem, because when I am going to need lambda functionality for example, should I turn to phoenix? Or to the lambda package? Personally I would prefer either of the following two: a) Phonix is split up into several smaller packages with most of them being merged/combined with exisiting ones. b) Phonix is renamed into something like Boost::FunctionalProgramming and is merged with the exisiting packages. With both options, when I am going to need lambda or bind in the future, I will know where to look for them. The text on the first page of the documentation supports these thoughts IMHO: "One can extract and use only a small subset of the full library, literally tearing the library into small pieces, without fear that the pieces won't work anymore." My vote: ======== 1) Before accepting Phoenix as boost library, its relationships with (competing?) packages of similar nature should be resolved. Having everything more than once is not helpful. Personally I am in favor of smaller, more focused packages, so I would choose option a) 2) Before accepting it as boost library, a different name should be chosen. One that tells what the library is about. Regards, Roland PS: As for the background information: - Are you knowledgeable about the problem domain? I am not an FP expert, but I've tasted blood and want more... - What is your evaluation of the design? Not being an expert, I say, I am quite fascinated :-) - What is your evaluation of the implementation? Haven't looked into the code, yet - What is your evaluation of the documentation? I am going to send se separate mail. - What is your evaluation of the potential usefulness of the library? As I wrote above, I think it would gain from being merged with existing libraries either to form a greater whole or to form several specialized packages. - Did you try to use the library? With what compiler? Did you have any problems? Yes, I played with the "real life" example, tried to turn it into a a real "real life" example and failed utterly. Code is attached. Certainly shows that I am not an expert ;-) - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Several hours of reading and playing around, collecting thoughts in this mail and the next one in parallel. Not nearly as much as I wanted, but I got stuck with the documentation Robert Ramey wrote:

...

I spent some time looking at this library. I'm looking at the documentation in release 1.36 for phoenix in the spirit library documentation.

Here are a few observations:

I don't really know enough about functional programming in order to write a revew. My perspective is of someone who is interested in this subject and wants to use phoenix as a vehicule to learn more about it and experiment with it to see to what extent it can help me with the programming problems that I come upon in my daily work.

I don't like the current trend in assigning "cute" names to libraries. E.G. spirit, phoenix, proto, xpressive, oven, - I'm sure there are others. The universe libraries is sufficiently large that given a problem, I'm included to scan a list of library names and drill down into those whose names suggest they might help on my current problem. These names don't help me with that. I don't expect anyone to change a current name, and It's not a huge issue - but it is a minor annoyance.

When I perused the library documentation, I was left with the idea that I had a general understanding of what it does and that I could make use of it should I decide to. This struck a very positive note for me.

However, I would much like to see a few simple examples of complete applications which show how the library can actually shorten/and/or improve the final result. The "First Practical Example" is too trivial and it seems to be the only real example.

After writing the above, I looked up the references cited in the documentation. I found that I had the same complaint about most of them. The John Hughes paper (1989!) did have some interesting examples. Maybe implementing the newton-raphson method on in terms of phoenix might have helped me.

Robert Ramey

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Zeljko Vrba

8:35 p.m.

On Mon, Sep 29, 2008 at 10:04:00PM +0200, Roland Bock wrote:

...

Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it.

Had you looked at the bottom of this page http://tinyurl.com/5xgx5f you would have seen that the library is dedicated to Joel's (passed away) daughter Phoenix. Personally, I think that the naming is rather irrelevant when all libraries are anyway listed on the boost main page: http://www.boost.org/doc/libs/1_36_0 together with a short description. And if we're going to start nitpicking, there's already a bunch of very uninformative names (Any, Assign, Enable If, Function, GIL, Iostreams [like, what the hell, isn't this already in the standard library], etc.)

Klaus Backert

30 Sep 30 Sep

1:46 a.m.

Am 29.09.2008 um 22:35 schrieb Zeljko Vrba:

...

On Mon, Sep 29, 2008 at 10:04:00PM +0200, Roland Bock wrote:

...
Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it.

It's just my experience, that it has been – and still is – more difficult – than it has to be – for me as a newcoming boost user to find out which libraries match the problems I have to solve.

...

...
Had you looked at the bottom of this page

http://tinyurl.com/5xgx5f

you would have seen that the library is dedicated to Joel's (passed away) daughter Phoenix.

And your point is ...?

...

Personally, I think that the naming is rather irrelevant when all libraries are anyway listed on the boost main page:

Personally, I think that the naming is rather *relevant* when searching through such a lot of libraries, and when the descriptions on the main page are – well – not all very helpful (the written-by- people-who-already-know phenomenon?).

...

http://www.boost.org/doc/libs/1_36_0

together with a short description.

And if we're going to start nitpicking, there's already a bunch of very uninformative names (Any, Assign, Enable If, Function, GIL, Iostreams [like, what the hell, isn't this already in the standard library], etc.)

Bad enough. No reason to proceed. There are good examples, like array, smart_ptr, and lambda which are pertinent technical terms everybody in the business should know about (If there does not exist *one* technical term, or *one* metaphor, or *one* abbreviation, then break the library down into several parts). Instead of "Phoenix" use "Functional Programming"! And why? Because the library description says "Phoenix enables Functional Programming ...", and the library introduction says: "The focus is ... on usefulness and practicality ...". If you want usefulness and practicality, then give it a name which is useful and practical!

Joel de Guzman

4:56 a.m.

Klaus Backert wrote:

...

Am 29.09.2008 um 22:35 schrieb Zeljko Vrba:

...
On Mon, Sep 29, 2008 at 10:04:00PM +0200, Roland Bock wrote:

...
Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it.

It's just my experience, that it has been – and still is – more difficult – than it has to be – for me as a newcoming boost user to find out which libraries match the problems I have to solve.

...
...
Had you looked at the bottom of this page

http://tinyurl.com/5xgx5f

you would have seen that the library is dedicated to Joel's (passed away) daughter Phoenix.

And your point is ...?

Please... I don't want to go into naming wars again. It's just not productive and deviates from the more important matters. As far as I can tell, there's nothing in Boost that requires a library to follow a certain naming convention. I want to reserve the right to naming. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

Zeljko Vrba

6:12 a.m.

On Tue, Sep 30, 2008 at 03:46:20AM +0200, Klaus Backert wrote:

...

...
you would have seen that the library is dedicated to Joel's (passed away) daughter Phoenix.

And your point is ...?

Show some respect. Joel is giving away *for free* several great libraries, so he should at least have the freedom to name them as he likes. Especially when the name is not arbitrary.

...

Instead of "Phoenix" use "Functional Programming"! And why? Because

No, that would be the wrong name because the library does not provide the tools one expects from a functional programming language -- cons lists, huge library of algorithms for list manipulation (see Haskell's standard prelude), pattern matching, etc. The closest "meaningful" name would be "Lazy Functions", but hey, if you don't already have the necessary background, it's again meaningless! Abstract name forces you at least to read the introduction to a library. == Now, to become more on topic: the manual states "Phoenix version 2, this version, will probably be the last release of the library. Phoenix v2 will be the basis of the Phoenix and BLL merger." Another fact: Phoenix2 *is* already accepted into boost as part of Spirit; bringing it out to the top level is nothing but a minor structural change.. So I'm forced to ask: why was Phoenix even submitted "for acceptance" when 1) it is already 'accepted', and 2) Joel states that it has reached the end of development?

Joel de Guzman

6:57 a.m.

Zeljko Vrba wrote:

...

Now, to become more on topic: the manual states "Phoenix version 2, this version, will probably be the last release of the library. Phoenix v2 will be the basis of the Phoenix and BLL merger."

Another fact: Phoenix2 *is* already accepted into boost as part of Spirit; bringing it out to the top level is nothing but a minor structural change..

So I'm forced to ask: why was Phoenix even submitted "for acceptance" when 1) it is already 'accepted', and 2) Joel states that it has reached the end of development?

CC'ing the Boost Dev List. Let me clarify. Phoenix has not reached the end of development. It's the name that /might/ (if all goes according to plan) cease to exist when Phoenix becomes Lambda: Yep, that's the plan. For the first question, when Spirit was reviewed, Phoenix was not part of the review. It existed only as a sub-library of Spirit. Thirdly, bringing Phoenix into the top level will not be a minor structural change. There are several factors that are being deliberated upon (in the other list). First and foremost is compatibility with Lambda, Boost.Bind and std::bind, plus of course the current Phoenix V2, which, to some extent will be forced to break the API for the sake of the other libraries and to play well in the grand unification. There's also the possibility of assimilating Boost.Bind (thanks to Peter for giving the nod) for modern compilers, thus having only one version of bind for all. Boost.Bind will of course still continue to exist (it works with more compilers, even old broken ones like VC6 and Borland 5). Ah, not to mention that there's a port (by Eric Niebler) of Phoenix to proto that we call Phoenix V3. Take all these, plus the numerous suggestions, comments, and we have exciting times ahead of us. I urge you to join in the (exciting!) discussions happening in the boost dev list. It's hard to keep track when there are 2 separate lists involved in the review. I'm trying my best to CC both if I can. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

Joel de Guzman

7:20 a.m.

Joel de Guzman wrote:

...

Zeljko Vrba wrote:

...
Now, to become more on topic: the manual states "Phoenix version 2, this version, will probably be the last release of the library. Phoenix v2 will be the basis of the Phoenix and BLL merger."

[...]

...

Let me clarify. Phoenix has not reached the end of development. It's the name that /might/ (if all goes according to plan) cease to exist when Phoenix becomes Lambda: Yep, that's the plan.

I should probably restate that part of the docs to make it clear: "Phoenix version 2, this version, will probably be the last release of the library under the name." The plan (and it seems that there's consensus) is that Phoenix V3 will be Lambda V2 and supercede Boost.Bind on modern compilers on which Phoenix works. I don't know about you, but I think this is all very exciting! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

Zeljko Vrba

7:41 a.m.

On Tue, Sep 30, 2008 at 03:20:32PM +0800, Joel de Guzman wrote:

...

I should probably restate that part of the docs to make it clear:

"Phoenix version 2, this version, will probably be the last release of the library under the name."

I think that the following paragraph

...

The plan (and it seems that there's consensus) is that Phoenix V3 will be Lambda V2 and supercede Boost.Bind on modern compilers on which Phoenix works.

(suitably reformulated) should also be added to the above sentence. This will remove all doubts about the future of these libraries. [If you just have the single above sentence, a bunch of questions again come to mind..]

...

I don't know about you, but I think this is all very exciting!

Yes, it is very exciting, but I don't have much free time for active participation.. (much of my "free" time is also being spent on work at the moment..) I can only say that I very much like the direction in which the things are moving. It's only sad that few Boost developers care about the Solaris platform ;( [I'm *not* pointing towards you.] PS: Have you considered integrating stuff from FC++ into Phoenix [or inviting the FC++ team to integrate it]? FC++ has also been submitted for inclusion into boost (and rejected); it would be a real shame that because of this FC++ just fades away.. By "stuff" I mean primarily the (lazy) List library.

Jeff Flinn

12:07 p.m.

Zeljko Vrba wrote:

...

On Mon, Sep 29, 2008 at 10:04:00PM +0200, Roland Bock wrote:

...
Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it.

Had you looked at the bottom of this page

http://tinyurl.com/5xgx5f

you would have seen that the library is dedicated to Joel's (passed away) daughter Phoenix.

Personally, I think that the naming is rather irrelevant when all libraries are anyway listed on the boost main page:

http://www.boost.org/doc/libs/1_36_0

together with a short description.

And if we're going to start nitpicking, there's already a bunch of very uninformative names (Any, Assign, Enable If, Function, GIL, Iostreams [like, what the hell, isn't this already in the standard library], etc.)

I think naming was not an issue when the website had a "Category" view as well as the alphabetical listing. Spirit, regex, xpressive were under the text processing category... so I knew to look at these and see which met my needs. The new SortBy while nice, is lacking in this regard. Jeff Flinn

Joel de Guzman

2:19 p.m.

Jeff Flinn wrote:

...

Zeljko Vrba wrote:

...
On Mon, Sep 29, 2008 at 10:04:00PM +0200, Roland Bock wrote:

...
Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it. Had you looked at the bottom of this page

http://tinyurl.com/5xgx5f

you would have seen that the library is dedicated to Joel's (passed away) daughter Phoenix. Personally, I think that the naming is rather irrelevant when all libraries are anyway listed on the boost main page:

http://www.boost.org/doc/libs/1_36_0

together with a short description.

And if we're going to start nitpicking, there's already a bunch of very uninformative names (Any, Assign, Enable If, Function, GIL, Iostreams [like, what the hell, isn't this already in the standard library], etc.)

I think naming was not an issue when the website had a "Category" view as well as the alphabetical listing. Spirit, regex, xpressive were under the text processing category... so I knew to look at these and see which met my needs. The new SortBy while nice, is lacking in this regard.

For some reason, it's still there (if you google it): http://www.boost.org/doc/libs/1_36_0/libs/libraries.htm But I can't seem to get to it from the boost site. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

peter_foelsche＠agilent.com

6:52 p.m.

New subject: boost::mpl::max_element and boost::mpl::vector

I have two vectors (CDB and CDB1) containing boolean. I want to make certain that if a bit in the second vector is set, it must also be set in the first vector. template struct CTargetEqualOrGreater { static const bool value = boost::mpl::deref< boost::mpl::max_element< boost::mpl::transform< CDB, CDB1, boost::mpl::not_< boost::mpl::or_< boost::mpl::and_< boost::mpl::not_boost::mpl::_1, boost::mpl::not_boost::mpl::_2 >, boost::mpl::_1 > > > > >::type::value == 0; }; ... BOOST_MPL_ASSERT( (CTargetEqualOrGreater::value)); But this does not compile.

peter_foelsche＠agilent.com

7:14 p.m.

New subject: boost::mpl::max_element and boost::mpl::vector

I figured it out myself: template struct CTargetEqualOrGreater { typedef CTargetEqualOrGreater type; typedef typename boost::mpl::transform< CDB, CDB1, boost::mpl::not_< boost::mpl::or_< boost::mpl::and_< boost::mpl::not_boost::mpl::_1, boost::mpl::not_boost::mpl::_2 >, boost::mpl::_1 > > >::type CBoolVector; typedef typename boost::mpl::max_element<CBoolVector>::type CMaxElement; typedef typename boost::mpl::deref<CMaxElement>::type CDeRef; static const bool value = CDeRef::value == false; }; -----Original Message----- From: FOELSCHE,PETER (A-SantaClara,ex1) Sent: Tuesday, September 30, 2008 11:53 To: 'boost-users@lists.boost.org' Subject: [Boost-users] boost::mpl::max_element and boost::mpl::vector I have two vectors (CDB and CDB1) containing boolean. I want to make certain that if a bit in the second vector is set, it must also be set in the first vector. template struct CTargetEqualOrGreater { static const bool value = boost::mpl::deref< boost::mpl::max_element< boost::mpl::transform< CDB, CDB1, boost::mpl::not_< boost::mpl::or_< boost::mpl::and_< boost::mpl::not_boost::mpl::_1, boost::mpl::not_boost::mpl::_2 >, boost::mpl::_1 > > > > >::type::value == 0; }; ... BOOST_MPL_ASSERT( (CTargetEqualOrGreater::value)); But this does not compile.

peter_foelsche＠agilent.com

9:07 p.m.

New subject: mpl code does not compile with GNU-C++ 4.2.2

#include #include #include #include #include #include #include #include #include #include #include <utility> #include #include #include #include #include #include #include #include #include #include template<typename CDB> struct CDer { typedef CDer<CDB> CThis; typedef boost::mpl::zip_view > CMerged; static const unsigned int XSIZE = boost::mpl::size<CDB>::value; template struct CCreatePair { CMultiply &m_rOp; CCreatePair(CMultiply& op) : m_rOp(op) { } typedef void result_type; template<typename T> struct wrap { }; template<typename T> void operator ()(wrap<T>) const { typedef typename boost::mpl::front<T>::type first; typedef typename boost::mpl::back<T>::type second; m_rOp(std::make_pair(first::value, second::value)); } }; template<typename CDB1> struct CCopy:private boost::noncopyable { CThis &m_r0; const CDer<CDB1> &m_r1; unsigned int m_iPos; CCopy(const CDer<CDB1> &_r1, CThis &_r0) :m_r0(_r0), m_r1(_r1), m_iPos(0) { } void operator()(const std::pair &_r) { } }; template<typename CDB1> struct CTargetEqualOrGreater { typedef CTargetEqualOrGreater<CDB1> type; typedef typename boost::mpl::transform< CDB, CDB1, boost::mpl::not_< boost::mpl::or_< boost::mpl::and_< boost::mpl::not_boost::mpl::_1, boost::mpl::not_boost::mpl::_2 >, boost::mpl::_1 > > >::type CBoolVector; typedef typename boost::mpl::max_element<CBoolVector>::type CMaxElement; typedef typename boost::mpl::deref<CMaxElement>::type CDeRef; static const bool value = CDeRef::value == false; }; CDer(void) { } template<typename CDB1> CDer(const CDer<CDB1> &_r) { CCopy<CDB1> sCopy(_r, *this); CCreatePair sCreatePair(sCopy); boost::mpl::for_each::wrapboost::mpl::_1 >(sCreatePair); BOOST_MPL_ASSERT( (CTargetEqualOrGreater<CDB1>)); } template<typename CDB1> CThis &operator=(const CDer<CDB1> &_r) { CCopy<CDB1> sCopy(_r, *this); CCreatePair sCreatePair(sCopy); boost::mpl::for_each::wrapboost::mpl::_1 >(sCreatePair); BOOST_MPL_ASSERT( (CTargetEqualOrGreater<CDB1>)); return *this; } }; int main() { typedef CDer< boost::mpl::vector< boost::mpl::true_, boost::mpl::true_, boost::mpl::true_, boost::mpl::true_ > > CDerBSIM3; const CDerBSIM3 b; const CDerBSIM3 a(b); return 0; } the compiler says: main.cpp: In constructor 'CDer<CDB>::CDer(const CDer<CDB1>&)': main.cpp:96: error: parse error in template argument list main.cpp: In member function 'CDer<CDB>& CDer<CDB>::operator=(const CDer<CDB1>&)': main.cpp:104: error: parse error in template argument list This is exactly the for_each line. Peter

Steven Watanabe

9:15 p.m.

New subject: mpl code does not compile with GNU-C++ 4.2.2

AMDG peter_foelsche@agilent.com wrote:

...

boost::mpl::for_each::wrapboost::mpl::_1 >(sCreatePair)

boost::mpl::for_each ::template wrapboost::mpl::_1 >(sCreatePair) In Christ, Steven Watanabe

Jeff Flinn

8:07 p.m.

...

...
I think naming was not an issue when the website had a "Category" view as well as the alphabetical listing. Spirit, regex, xpressive were under the text processing category... so I knew to look at these and see which met my needs. The new SortBy while nice, is lacking in this regard.

For some reason, it's still there (if you google it): http://www.boost.org/doc/libs/1_36_0/libs/libraries.htm

But I can't seem to get to it from the boost site.

Yeah, I thought I stumbled on it somehow recently but couldn't get back to it from the new website. That page looks like the old style page formatting. I wonder what the current SortBy Key is supposed to do. I don't see any particular grouping with this option. Perhaps it was intended to provide a Catergory sort order? Jeff

Joel de Guzman

4:17 a.m.

Roland Bock wrote: Hi Roland, It's unfortunate that there are two lists where the review is taking place. Most of the issues you mention below are already discussed in the boost.devel list. I would urge you to see the history of the review that has transpired so far. I'm CC'ing the Boost.Devel list.

...

Name: ====== Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it. It also helps the library's developers and contributors to focus. With a name like Phoenix, the sky is the limit. Remember the time when Firefox aka Mozilla was called Phoenix?

The same is true for Spirit. If nobody had told me to use Spirit for parsing, I probably would never have come to use it. And looking at Spirit, I was quite astonished to find the Phoenix things in there.

To me Spirit looked like small collection of libraries inside a bigger collection of libraries (boost). I bet that there would have been quite a different development with a different, more focused name.

The name "Phoenix" does neither help to find the library nor does it help to decide whether to have a certain feature included or not. Want MPL inside Phoenix? Er, well, yes, why not? Want Graph functionality? Yeah, would be great to be able to draw up relationships between Phoenix actors. Sorry, I might be exaggerating...

Points well taken. However, I would like to preserve that right. In as much as I am not forcing anyone to choose names, I don't relish the thought that I'll be forced to choose some name like "Boost::FunctionalProgramming".

...

Phoenix: ======== Now Phoenix is about to be taken out of Spirit which is good for both Spirit and Phoenix, I guess. From what I have read so far, Phoenix seems to have very powerful features. It deserves to live outside Spirit.

But many of Phoenix' features seem to be variants (improved, probably) of exisiting things like bind, lambda, ref, functional. I consider this a problem, because when I am going to need lambda functionality for example, should I turn to phoenix? Or to the lambda package?

Personally I would prefer either of the following two:

a) Phonix is split up into several smaller packages with most of them being merged/combined with exisiting ones.

b) Phonix is renamed into something like Boost::FunctionalProgramming and is merged with the exisiting packages.

With both options, when I am going to need lambda or bind in the future, I will know where to look for them.

The text on the first page of the documentation supports these thoughts IMHO:

"One can extract and use only a small subset of the full library, literally tearing the library into small pieces, without fear that the pieces won't work anymore."

May I request you to review the discussions and history/context from the Boost list? These issues are part of the discussions. I would urge you to reply on these matters in the relevant threads.

...

My vote: ======== 1) Before accepting Phoenix as boost library, its relationships with (competing?) packages of similar nature should be resolved. Having everything more than once is not helpful. Personally I am in favor of smaller, more focused packages, so I would choose option a)

Understood. I hope the discussions/threads related to this matters will shed light on what the current consensus is.

...

2) Before accepting it as boost library, a different name should be chosen. One that tells what the library is about.

Point well taken. Is it a condition for your vote?

...

PS: As for the background information:

- Are you knowledgeable about the problem domain? I am not an FP expert, but I've tasted blood and want more...

:-)

...

- What is your evaluation of the design? Not being an expert, I say, I am quite fascinated :-)

- What is your evaluation of the implementation? Haven't looked into the code, yet

- What is your evaluation of the documentation? I am going to send se separate mail.

- What is your evaluation of the potential usefulness of the library? As I wrote above, I think it would gain from being merged with existing libraries either to form a greater whole or to form several specialized packages.

Agreed. That's exactly the current consensus. FYI, that was the plan and one of the prime reasons for the review. You'll know for sure once you learn more about the history and context as they are being discussed in the other list.

...

- Did you try to use the library? With what compiler? Did you have any problems? Yes, I played with the "real life" example, tried to turn it into a a real "real life" example and failed utterly. Code is attached. Certainly shows that I am not an expert ;-)

Here's the correct code: // Find the first odd number in container c iterator it = find_if(c.begin(), c.end(), bind(&simple::value_, arg1) % 2 == 1); if (it != c.end()) cout << it->value_ << endl; // if found, print the result

...

- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Several hours of reading and playing around, collecting thoughts in this mail and the next one in parallel. Not nearly as much as I wanted, but I got stuck with the documentation

Thank you for your review. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

Roland Bock

7:11 a.m.

Hi Joel, sorry, I am not on the boost.devel list and I did not read the discussion there. I admit that I am new to public review and obviously did look not in all available places. I promise to catch up :-) My vote does not depend on the name of the library. I consider the things I learned about Phoenix so far pretty amazing! And I am in favor of the library being accepted in boost. I just wanted to state that from my limited experience (about 15 years of development and about 10 years of coordinating a small team), I say that selfexplanatory names for variables, methods, classes and libraries are very helpful in the long run. I certainly don't want to force anybody. I had hoped to be able to convince you. But again, my vote does not depend on it :-) Thanks for your answers! Regards, Roland Joel de Guzman wrote:

...

Roland Bock wrote:

Hi Roland,

It's unfortunate that there are two lists where the review is taking place. Most of the issues you mention below are already discussed in the boost.devel list. I would urge you to see the history of the review that has transpired so far.

I'm CC'ing the Boost.Devel list.

...
Name: ====== Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it. It also helps the library's developers and contributors to focus. With a name like Phoenix, the sky is the limit. Remember the time when Firefox aka Mozilla was called Phoenix?

The same is true for Spirit. If nobody had told me to use Spirit for parsing, I probably would never have come to use it. And looking at Spirit, I was quite astonished to find the Phoenix things in there.

To me Spirit looked like small collection of libraries inside a bigger collection of libraries (boost). I bet that there would have been quite a different development with a different, more focused name.

The name "Phoenix" does neither help to find the library nor does it help to decide whether to have a certain feature included or not. Want MPL inside Phoenix? Er, well, yes, why not? Want Graph functionality? Yeah, would be great to be able to draw up relationships between Phoenix actors. Sorry, I might be exaggerating...

Points well taken. However, I would like to preserve that right. In as much as I am not forcing anyone to choose names, I don't relish the thought that I'll be forced to choose some name like "Boost::FunctionalProgramming".

...
Phoenix: ======== Now Phoenix is about to be taken out of Spirit which is good for both Spirit and Phoenix, I guess. From what I have read so far, Phoenix seems to have very powerful features. It deserves to live outside Spirit.

But many of Phoenix' features seem to be variants (improved, probably) of exisiting things like bind, lambda, ref, functional. I consider this a problem, because when I am going to need lambda functionality for example, should I turn to phoenix? Or to the lambda package?

Personally I would prefer either of the following two:

a) Phonix is split up into several smaller packages with most of them being merged/combined with exisiting ones.

b) Phonix is renamed into something like Boost::FunctionalProgramming and is merged with the exisiting packages.

With both options, when I am going to need lambda or bind in the future, I will know where to look for them.

The text on the first page of the documentation supports these thoughts IMHO:

"One can extract and use only a small subset of the full library, literally tearing the library into small pieces, without fear that the pieces won't work anymore."

May I request you to review the discussions and history/context from the Boost list? These issues are part of the discussions. I would urge you to reply on these matters in the relevant threads.

...
My vote: ======== 1) Before accepting Phoenix as boost library, its relationships with (competing?) packages of similar nature should be resolved. Having everything more than once is not helpful. Personally I am in favor of smaller, more focused packages, so I would choose option a)

Understood. I hope the discussions/threads related to this matters will shed light on what the current consensus is.

...
2) Before accepting it as boost library, a different name should be chosen. One that tells what the library is about.

Point well taken. Is it a condition for your vote?

...
PS: As for the background information:

- Are you knowledgeable about the problem domain? I am not an FP expert, but I've tasted blood and want more...

:-)

...
- What is your evaluation of the design? Not being an expert, I say, I am quite fascinated :-)

- What is your evaluation of the implementation? Haven't looked into the code, yet

- What is your evaluation of the documentation? I am going to send se separate mail.

- What is your evaluation of the potential usefulness of the library? As I wrote above, I think it would gain from being merged with existing libraries either to form a greater whole or to form several specialized packages.

Agreed. That's exactly the current consensus. FYI, that was the plan and one of the prime reasons for the review. You'll know for sure once you learn more about the history and context as they are being discussed in the other list.

...
- Did you try to use the library? With what compiler? Did you have any problems? Yes, I played with the "real life" example, tried to turn it into a a real "real life" example and failed utterly. Code is attached. Certainly shows that I am not an expert ;-)

Here's the correct code:

// Find the first odd number in container c iterator it = find_if(c.begin(), c.end(), bind(&simple::value_, arg1) % 2 == 1);

if (it != c.end()) cout << it->value_ << endl; // if found, print the result

...
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Several hours of reading and playing around, collecting thoughts in this mail and the next one in parallel. Not nearly as much as I wanted, but I got stuck with the documentation

Thank you for your review.

Regards,

Joel de Guzman

7:27 a.m.

Roland Bock wrote:

...

Hi Joel,

sorry, I am not on the boost.devel list and I did not read the discussion there. I admit that I am new to public review and obviously did look not in all available places. I promise to catch up :-)

No problem :-)

...

My vote does not depend on the name of the library. I consider the things I learned about Phoenix so far pretty amazing! And I am in favor of the library being accepted in boost.

I just wanted to state that from my limited experience (about 15 years of development and about 10 years of coordinating a small team), I say that selfexplanatory names for variables, methods, classes and libraries are very helpful in the long run. I certainly don't want to force anybody. I had hoped to be able to convince you. But again, my vote does not depend on it :-)

Well, see my other (related) post. I think you will be happy :-)

...

Thanks for your answers!

Most welcome! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

Joel de Guzman

3:02 a.m.

Robert Ramey wrote:

...

I spent some time looking at this library. I'm looking at the documentation in release 1.36 for phoenix in the spirit library documentation.

Here are a few observations:

I don't really know enough about functional programming in order to write a revew. My perspective is of someone who is interested in this subject and wants to use phoenix as a vehicule to learn more about it and experiment with it to see to what extent it can help me with the programming problems that I come upon in my daily work.

I don't like the current trend in assigning "cute" names to libraries. E.G. spirit, phoenix, proto, xpressive, oven, - I'm sure there are others. The universe libraries is sufficiently large that given a problem, I'm included to scan a list of library names and drill down into those whose names suggest they might help on my current problem. These names don't help me with that. I don't expect anyone to change a current name, and It's not a huge issue - but it is a minor annoyance.

With all due respect, I'd like to preserve that right. It's my library anyway. In as much as I am not forcing you to provide a "cute" name for Serialization, please don't force me to do acronyms or some such. On a related note, I'm happy with the cute name "Boost" Libraries, instead of something bland like... hah! I can't even think of a name or acronym. Hmmm... C++ SLE? "standard library extensions". Yuk!

...

When I perused the library documentation, I was left with the idea that I had a general understanding of what it does and that I could make use of it should I decide to. This struck a very positive note for me.

However, I would much like to see a few simple examples of complete applications which show how the library can actually shorten/and/or improve the final result. The "First Practical Example" is too trivial and it seems to be the only real example.

After writing the above, I looked up the references cited in the documentation. I found that I had the same complaint about most of them. The John Hughes paper (1989!) did have some interesting examples. Maybe implementing the newton-raphson method on in terms of phoenix might have helped me.

Agreed! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

5885

Age (days ago)

5886

Last active (days ago)

List overview

Download

21 comments

9 participants

participants (9)

Hartmut Kaiser
Jeff Flinn
Joel de Guzman
Klaus Backert
peter_foelsche＠agilent.com
Robert Ramey
Roland Bock
Steven Watanabe
Zeljko Vrba