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