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
>>> 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):
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
-- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk