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

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-07-01 08:53:10

On Tue, Jul 1, 2008 at 2:30 PM, Joel de Guzman
<joel_at_[hidden]> wrote:
<snip>
> One of the obstacles towards merger is that Lambda has some
> quirks of its own that makes it difficult to provide full backwards
> compatibility. Eric ported Phoenix 2.0 to proto, making it Phoenix
> 3.0. In the course of the development, Eric and I seem to both
> coming to the conclusion that the best route is to leave the
> Lambda codebase alone and make Phoenix 3.0 the new lambda
> (i.e. lambda 2.0). And, similar to what we did with Spirit2,
> we can have an interim release that bundles both the old lambda
> and the new. With this approach, code that uses Lambda should
> should not do anything special. Users who want to take advantage
> of the features of Lambda-2 (aka Phoenix) can upgrade with some
> minimal code tweaks. If this is an acceptable solution to all
> parties involved (Jaakko?), then we can do this as early as 1.37
> (alas, it's too late for 1.36).
>
> Your comments very welcome!
>

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.

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.

- 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).

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

-- 
gpd