From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-04-02 13:05:31
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 ,
> > 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
> (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++.
Anyways, I agree that optionally lazy functions might be confusing.
> Anyway, egg::unfuse with "contains_bind_expression<FusionSeq>" trait
> can easily implement such a optionally-lazy adaptor.
> >> 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
> 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
As a bonus, a regularized, stateless, boost.lambda functor will
initialize itself with a default constructed lambda.
Figuring out if a lambda is stateless might be non trivial :) (but,
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? (for
example, did you use this functionality when implementing oven?).
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk