Subject: Re: phoenix lambda-lambda for_each example
From: Aleksey Gurtovoy <[email-masked]>
To: Jaakko Jarvi <[email-masked]>
Cc: Joel de Guzman <[email-masked]>, Noah Stein <[email-masked]>, David Abrahams <[email-masked]>
Date: Thu, 04 Mar 2004 04:07:09 -0600

Jaakko Jarvi writes:
> One more point...
> In Joel's suggestion, basically all arguments
> on parameter slots  expecting  a function object will be
> interpreted as lambdas. It first seemed a bit scary that this
> information is only at the defintion of the function that is being
> called and there is no visual clue at the call site
> where the boundaries of lambdas are. But after pondering this
> for a while, it worries me less.

That was basically my reaction, too. 

It's interesting how compile-time and run-time lambdas differ here: in
MPL, there is no way to automatically determine the implicit scope:

     // sums a sequence of sequence of numbers 
     typedef fold< _1, int_<0> 
         , fold< _2, _1, plus<_1,_2> > 
     //                  ^^^^^^^^^^    third scope, same question
     //    ^^^^^^^^^^^^^^^^^^^^^^^^^^^ second scope, but how do we know?
        > f; 

, at least without some additional metafunction's markup which would
indicate that 'fold's third argument is a predicate, e.g.:

    template< typename T1, typename T2, typename T3 >
    struct scope< fold<T1,T2,T3> >
    {
        typedef fold<T1,T2,scope<T3> > type;
    }; 

In contrast, if you want to add implicit scope wrapping to a run-time
lambda, it almost comes "for free" since lambda subexpressions are
passed through anyway:

    fold(_1, 0, fold(_2, _1, _1 + _2))
    //                       ^^^^^^^ passed through the nested 'fold'
    //                               which has a chance to wrap it in
    //                               a scope

so it's just a matter of wrapping them accordingly.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering