for_each(arg1, lambda(_a = arg2) [ push_back(arg1, _a) ] )
... I'm not an expert on modern FP, but the above lambda doesn't seem like a classic lambda (as in lambda calculus and Lisp) to me. Now that I've seen what Phoenix can do, I think that, were I to design a Boost.Lambda2, I'd probably go with a classic lambda of the form lambda( _x, _y )[ _x + _y ] where the inner _x + _y is not a function object, and it is the lambda[] that turns it into one. (That is, the evaluation of an inner expression would be done with eval(expr, args...) and not with expr(args...).) Local state would look like lambda( _x, _a = 0 )[ _a += _x ] and one can also extend this to lambda( byval, ... ) and lambda( byref, ... ) to control the default capture behavior. I'd spell function application inside a lambda as apply( f, x ) and not as bind, leaving the latter as an alias for lambda[ apply ]. So \f \x f (f x) would be lambda( _f )[ lambda( _x ) [ apply( _f, apply( _f, _x ) ) ] ] Using the above example as a test for this theory:
for_each(arg1, lambda(_a = arg2) [ push_back(arg1, _a) ] )
In lambda terms, it's something like \x,y for_each( x, \z push_back( z, y ) ) so (with lazy for_each and push_back): lambda( _x, _y )[ for_each( _x, lambda( _z )[ push_back( _z, _y ) ] ) ] This implies that a lambda[] must be able to access an outer scope. I wonder how could one do that. :-) The outer lambda should be able to do some term rewriting, I guess. I should also be able to spell that as: lambda( _x, _y )[ for_each( _x, lambda( _x )[ push_back( _x, _y ) ] ) ] with the two _x being properly scoped.