Re: [boost] [Review] Phoenix review starts today, September 21st

Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: Eric Niebler (eric_at_[hidden])
Date: 2008-09-22 13:18:59

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