Review: lambda library

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-18 09:03:54

I think that the Lambda library should be accepted.

* Semantics

The two primary differences between the lambda bind and boost::bind are:

1. boost::bind uses mem_fn to support smart pointers:

 std::vector< boost::shared_ptr<X> > v;
 std::for_each( v.begin(), v.end(), boost::bind(&X::f, _1) );

The above unfortunately doesn't work with lambda; the bind in lambda is not
a drop-in replacement for boost::bind (as I'd have liked.)

2. Function object arity issues.

A boost::bind expression has the same arity regardless of context, i.e.
bind(&X::f, _1) always has arity [1, +inf). In lambda, the same expression
has a fixed arity that is context dependent; i.e. the expression by itself
has arity of 1, but in the context _2 + bind(&X::f, _1) that same expression
has arity of 2.

My experience with bind so far is that the flexible arity does not decrease
safety in significant ways, it simplifies the specification and the
implementation, and has proven useful in a number of cases where the user
intends to ignore the extra arguments. Having select1st always spelled '_1'
regardless of arity often makes code clearer.

Bind issues aside, I my overall impression is that the library is
overdesigned. I don't see for loops and try/catch blocks as necessary parts
of a lambda library; of course this is only my personal opinion, and I am
free to not use the features I don't find appropriate, so this is not a
major problem; it's only that this epic scope could prevent lambda from
being added to the standard library. ( Another feature I don't see a need of
is currying support. It seems added just because it's possible, not because
it solves a practical problem. I liked the original lean-and-mean lambda
from several years ago. :-) )

* Implementation

I'm getting warnings about boost::lambda::action, return_type,
return_type_1, return_type_2 having inconsistent declarations using both
'class' and 'struct', and unreferenced parameter warnings in selector<FIRST>
and selector<SECOND>.

The implementation doesn't scale well to more than three placeholders
AFAICS. This is not a major defect since code rarely needs _4 (I've
encountered it only once so far.)

_E is a reserved name.

I was unable to compile

 std::for_each( v.begin(), v.end(), (_1->*&X::f)() );

with both MSVC 7.01a and g++ 2.95.3.

* Documentation

The documentation doesn't have a reference section; it'll probably need one
in order for lambda to be considered for inclusion in the standard library.
:-)

--
Peter Dimov
Multi Media Ltd.