Re: [boost] Phoenix review

Subject: Re: [boost] Phoenix review
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-09-25 21:30:05

Doug Gregor wrote:
> On Sep 25, 2008, at 9:32 AM, Joel de Guzman wrote:
> 
>> Doug Gregor wrote:
>>> The alternatively, of course, is to use a syntax like:
>>>    case_<1>()[cout << val("one") << '\n', cerr << val("hello")],
>>> Interestingly, catch_<exception_type>()[ ... ] uses this same syntax; 
>>> why the discrepancy between case_ and catch_? Or did I miss something?
>>
>> Yeah, the discrepancy... It's one of the things I'm not quite satisfied
>> with. I do like the brackets [] but the empty parens stick out like
>> a sore thumb to me. At one point, I used the [] for the cases, changing
>> it later to the (). Fickle, ain't I?
>>
>> I'm open to suggestion. If we are to break the interface anyway,
>> I'd follow what the community wants.
> 
> Personally, I don't find the extra ()'s in case_<1>() all that horrible, 
> and I think it's the more regular to have all of the statements in []. 
> That said, unless something *else* is breaking the interface, this isn't 
> the thing that should be first to break the interface.

V3 breaks new grounds and breaks the interface significantly.
I'd still want to offer out-of-the-box backward compatibility
but I don't want to stifle changes for the better just
for backward compatibility. There's a way (I outlined one)
to have a gradual, stress free, move from old to new. We've
done it with Spirit2 without anyone noticing. We can do it
again.

>>> Anyway, now you have me trying to figure out how to tweak switch() to 
>>> fully support break_() and fall-through from one case to another :)
>>
>> Oh, that one! It's a tricky one to crack. Not much priority was
>> given on that since no one really asks for it. To be honest,
>> in terms of usability, I'd rather crack return_. I know it's
>> doable, but it's always been a balance. I tend to shy away
>> if the metaprogramming is getting quite involved. Not that
>> I don't like the challenge. It's just that I want to tame
>> down the compile times.
> 
> I'm not sure it's generally useful, but it sounds like a fun 
> metaprogramming challenge :)

Yeah it is. I welcome anyone with some spare time to burn :-)

>>> What level of interoperability can we expect among Boost.Bind, 
>>> Phoenix, Boost.Lambda, and TR1/C++0x's bind, if any?
>>
>> First should be the unification of the placeholders. I hate it when
>> I have to use different placeholders for different libraries when
>> they are essentially doing the same thing. The proto port is a good
>> step in that direction.
> 
> Yes, this is very important for usability.
> 
>> Beyond that, I'd like to hear from you and the community what you
>> want to expect. It's an open road. Phoenix has already done it's
>> job as a Spirit sidekick. It's just now that it's actively venturing
>> outside that sphere. I would love to have you and the community
>> plot its future.
> 
> 
> Well, I think Phoenix is the next-gen library to replace Boost.Lambda. 
> It's not that Lambda is bad---it's quite solid code---but we've learned 

Lambda is very solid code.

> a lot about how to build FP libraries in C++, and I'm sure that Jaakko 
> would love to be free of the maintenance burden :) So, my first 
> suggestion would be to deprecate Lambda in the first Boost release where 
> Phoenix is available, and remove it one or two releases afterward.

Yeah, that's essentially the plan I outlined.

> Bind is trickier. Phoenix does cover all of Bind's functionality (as far 
> as I can tell), but Bind current works on horribly broken compilers 
> where Phoenix just won't go (and shouldn't). Bind is also extremely 
> lightweight from a compile-time perspective, while Phoenix isn't quite 
> so small. 

Some numbers (preprocessing):

boost.bind       792K
phoenix1.bind	 853K
phoenix2.bind	3700K

Phoenix is not that heavy. The 3700K we see now is mostly due to
the use of Boost.Fusion and Boost.MPL beneath it. If you are using
those anyway, it's a win.

What I find most compelling with Boost.Bind is that it just works
on most compilers, even antiquated ones.

> Perhaps Peter has a different opinion on this, but I think 
> Bind and Phoenix will coexist in Boost for a very long time (and that's 
> okay).

I agree.

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