Giovanni Piero Deretta wrote:
On Wed, Apr 2, 2008 at 6:40 PM, shunsuke <pstade.mb@gmail.com> 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