Re: [boost] Giving names to formal parameters of lambda expressions: a named placeholder trick.

From: shunsuke (pstade.mb_at_[hidden])
Date: 2008-04-02 15:28:10

Giovanni Piero Deretta wrote:
> On Wed, Apr 2, 2008 at 6:40 PM, shunsuke <pstade.mb_at_[hidden]> wrote:
>> Giovanni Piero Deretta wrote:
>>  > I'm not saying that egg should support optionally-lazy functions [1],
>>  > it is ok if the lazy and non lazy variant have the same name. I just
>>  > want to be sure it is easy to define them.
>>
>>  I did't adopt "optionally-lazy" functions.
>>  As you show, many functions take FunctionObjects as arguments
>>  so that protect or unlambda is needed everywhere.
> 
> Well, as I said, the lambda[] really helps to make lambdas stand up in
> function calls. Also you have to wrap lambdas in 'regular' in may
> calls anyway so you might as wel just use lambda[]. After a while it
> becomes second nature, I simply use it even if it isn't strictly
> required.

I don't sure what lambda[] does.
Why not call bll::unlambda?
BTW, `regular` incurs a slight overhead, so that
I didn't adopt automatic "regular"ization in Oven.

>>  (I always follow the rationale "one name, one functionality".)
> 
> With real lambda abstraction, you wouldn't need a different name to
> call a function inside a lambda expression. I was trying to
> approximate it as much as possible in c++.

But real lambda abstraction introduces different syntax.

>>  >>  After all, Boost.Lambda bind and placeholders are not usable here.
>>  >
>>  > Why? Detail please :)
>>
>>  A functional call of `static_< always<F> >::type`
>>  is expanded to
>>       F()(a1,...,aN);
>>
>>  If F is a function pointer type, this will clearly crash.
>>  A "regular"ized Boost.Lambda functor also will crash because of uninitialized error.
>>  After all, we need a lambda functor such that default-constructed one is callable.
> 
> I think that we would need a way to inspect a lambda expression
> template and see if it is stateless (i.e. it is not closing over
> anything stateful). If it is stateful, static_ might abort compilation
> if initialized with 'stateless':
> 
> static_<always<F> >::type f = stateless; // does not compile if F is
> not stateless.

It is not a problem whether or not it is stateless.
The problem is whether or not Default-constructed one is callable without crash.
A default-constructed, regularized Boost.Lambda functor always crashes.

> Anyways, I see that you take great care to guarantee static
> initialization of stateful function objects. Do you really think this
> is a case that is worth supporting? What are the use cases?

A simple case is adapting a function-pointer.

> (for example, did you use this functionality when implementing oven?).

Oven functions in namespace scope are neither stateful nor pointers,
so that every function might be implemented using `static_`
without complicated macros.

> It seems to me that it complicates a lot the interface of the library
> (with tons of ugly macros). I understand that this functionality is
> opt-in (i.e. it is there only if you want it), but I feel
> unconfortable. May be I'm worring too much, but I think that it really
> makes the docs hard to follow.

I'm really afraid that those macros may keep users away from the library.

Regards,

-- 
Shunsuke Sogame