Re: [boost] Lambda Library

From: Oscar Fuentes (ofv_at_[hidden])
Date: 2002-02-07 16:47:00

Jaakko Jarvi <jajarvi_at_[hidden]> writes:

> > Well, I was unable to compile with gcc 3.0.3 (cygwin) and 2.95.3
> > (mingw). All test I've tried gave the same errors:
>  ...
> > 
> > The offending line in actions.hpp is
> > 
> >   BOOST_STATIC_CONSTANT(bool, value =
> >   (boost::is_base_and_derived<protectable, T>::value)); 
> > 
> > I'm using boost v 1.26.0. Do I need the current CVS sources?
> 
> Oh yes. is_base_and_derived was only added in January. :(

I've reported some hours ago that it works with 1.27.0. Somehow my
e-mail doesn't appear on the list so far. Just in case it was lost, I
repeat that gcc 3.0.3 (cygwin) gives this warning:

In file included from /t/boost/boost/lambda/lambda.hpp:19,
                 from control_structures.cpp:4:
/t/boost/boost/lambda/core.hpp:61: warning: identifier name `_1'
conflicts with GNU C++ internal naming strategy

Same for _2, _3.

No problem with gcc 2.95.3-6 (mingw) apart from the ones you detected.
 
> > " ... the lambda expression _1 + 1 can be seen as syntactic sugar
> > for the pseudo code bind(operator+, _1, 1). "
> > 
> > Should be "... the lambda expression 1 + _1 ...". This way the order
> > of arguments is the same for both expressions. Note that you later
> > define an asymmetric operator+ in another example.
> 
> Can you elaborate this? I can't see what is wrong with the argument 
> orderging? 

_1 + 1                   ---> operator+(?, 1)
bind(operator+, _1, 1)   ---> operator+(1, ?)

If operator+ is not symmetrical you have an inconsistency. (You define
an assymetric operator+ later:

"
However, there are cases when the return type cannot be deduced. For
example, suppose you have defined:
        
C operator+(A, B);
"

As you can see, this is a cheap correction. If you know C++ enough to
use the LL, you don't get caught by this :-)

> > "for_each(v.begin(), v.end(), _1 = bind(foo, _1));"
> > 
> > 'for_each' is a non-mutating algorithm. 'transform' is better for this
> > case.
> 
> Yes, for_each only requires the iterators to be InputIterators and I guess 
> that is why it is listed as non-modifying sequence operation.
> 
> I'm not sure what to do with this. To me code like this
> 
>   for_each(a.begin(), a.end(), ++_1); 
> 
> compared to this
> 
>   transform(a.begin(), a.end(), a.begin(), _1 + 1);
> 
> looks more intuitive.
> 
> Both will work, but the former may be (mis)using for_each in a 
> non-conformant way.

Right. As Gary Powell pointed out, that 'for_each' requirement is a
misfeature.
 
> We can always define 
> 
> lambda::for_each 
>  
> with a less constraining requirements to go around this :)

Oh, yes. Simply copy & paste std::for_each and omit the constraining
from the docs :-)

> 
> > (1) Having recursion would be great.
> > > (2) Having some kind of 'let' form 
> Something to think about :)

Hope this is not too difficult. It would open a new dimension for LL's
applications.

-- 
Oscar