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