Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: Eric Niebler (eric_at_[hidden])
Date: 2008-07-01 11:39:44

Giovanni Piero Deretta wrote:
> Yes please. The only thing that prevents me to use Phoenix every day
> is the fact that it is not an official boost library. If it were to
> become 'first class' personally I would be glad to ditch lambda.
> 
> Still I do not think that having both libraries for only one release
> is enough, probably boost should carry both of them for a while (3, 4
> releases), with explicit deprecation makers. Boost.lambda is a big and
> complex library, and it might take time to do a good conversion.

I agree.

> Now, some questions:
> 
> - Does Phoenix 3.0 (or 2.0) compile faster or slower than boost.lambda
> (on common expressions at least). Seen the care that Eric took to
> tweak Proto, I would say faster.

At the moment, Phoenix 3 (with Proto) compiles slower than Phoenix 2. I 
haven't benchmarked either against Lambda. Both Phoenix 2 and Lambda are 
surprisingly lightweight, so porting them to Proto without incurring a 
compile-time perf hit is a challenge. But I've only just begun 
optimizing it for compile times.

> - Last time I checked Phoenix only had a monomoprhic bind. If you have
> polymorphic functions you have to convert them to lazy functions. I
> think that adding a polymorphic bind (like lambda shouldn't be hard).
> 
> - Would it be possible to tell Phoenix the default capture mode, like
> in C++0x lambdas? By default lambda[] ( or any implicit lambda
> expression) would capture by value, but something like lambda_r[ ] (_r
> for reference) would get rid of many ref/cref at least for upward
> funargs. I do not know how easy is to do it, but I guess that proto
> make it possible (in fact I think that the reverse would be easier:
> capture by reference by default and then a top level lambdac would
> traverse the expression and convert any implicitly captured reference
> to a copy).

An interesting suggestion. Joel?

> - What are exactly the quirks that makes it hard to have full backward
> compatibility? Well except for 'sig' of course.

Wish I had written them all down. One that sticks in my mind is whether 
variables are captured by value or by reference. With Phoenix, it's very 
consistent ... all variables are captured by value, always. Lambda tries 
to be a bit more helpful, and it makes the rules more confusing, IMO. 
Most of the time, variables are captured by value, but a variable on the 
left of an assignment is captured by reference. This includes all the 
assignment operators, like plus-assign. So the following is a valid 
lambda expression:

    int i = 0;
    i += _1;

But in Phoenix, it would have to be:

    int i = 0;
    ref(i) += _1;

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com