On 2/3/11 8:04 PM, Joel de Guzman wrote:
You've just scratched the surface, and IMO, learned about the library in a way that I would not advice. To be honest, I never liked bind -- not a bit. If I did it my way, I'd write small modular phoenix functions just like you would in C++ or any FP language, but are fully curryable and lazy. It's very similar to what Local provides, albeit in C++ syntax instead of macros. By doing so, you avoid overly complex phoenix expressions and work closer to C++ but at the same time get all the benefits of FP.
As I said in my e-mail, I am sure the Phoenix is a wonderful tool after you have taken a lot of time to learn how to use it, and hopefully I will get the chance to become proficient at it myself one day. However, not all of us want to go through a lot of learning effort just to be able to conveniently create local functions. What is nice about Boost.Local is that you only have to learn about a couple of relatively simple concepts that have no dependence at all on the code that you want to embed in the function, whereas for Phoenix you are limited in what code you can include in the function until you have a great deal of mastery over the library, and the error message will give you no help at all in figuring out where you made a mistake so you need to have a lot of patience. Let me put this another way. Imagine that a new user comes along and thinks, "Gee, I have this snippet of code that I'd like to pass to another function inside a closure; does Boost have a library that makes this easier for me than writing lots of boilerplate to define a function object class?" If you say, "Sure! Check out the Phoenix library!" then they will likely have an experience similar to mine, conclude that the whole thing is more trouble than its worth, and go back to writing function object classes. However, if you say, "Sure! Check out the Local library!" then they will be much more likely to immediately see how to use it to solve their problem and will adopt it after a relatively shallow learning curve. So to repeat my thesis: Phoenix is a great library, but unless something significantly changes then I would strongly not recommend that it be viewed as making the existence of Local redundant. If Local is not included in Boost because theoretically Phoenix allows you to accomplish the same thing then this won't cause the users who need it to all learn how to use the theoretically nicer tool so much as it will cause many of them to use no tool from Boost at all. Local should be viewed as being complimentary to Phoenix rather competing with it, and it should be evaluated on its own merits. Cheers, Greg