On 9/17/2011 2:07 AM, Giovanni Piero Deretta wrote:
On Fri, Sep 16, 2011 at 6:09 PM, David Sankel <camior@gmail.com> wrote:
[...] The reason I said that phoenix "somewhat" gets around the bind heritage problems, which was obscure I admit, was because phoenix's use of traditional bind syntax still leaves a semantic hole.
If someone writes the following:
template< typename F > auto doSomething( F f ) -> decltype(...) { return bind( f, 15, _1) }
And then I call doSomething elsewhere like this,
doSomething( bind( g, 12, _1, _2 ) )
, then the result is something most likely unexpected for the user who knows what doSomething means (it returns a version of f that has 15 filled in as its first argument (λx. λy. x(15,y))), but hasn't read its implementation.
Boost.Lambda has unlambda, which is documented to prevent exactly this problem:
http://www.boost.org/doc/libs/1_47_0/doc/html/lambda/le_in_details.html#lamb...
With a quick search I couldn't find the phoenix equivalent of unlambda, but I'm sure there must be.
Phoenix does not need it because it has explicit 'lambda' (pun unintentional) which is required for passing in higher-order functions (e.g. to phoenix::for_each). IMO, unlambda is a hack around BLL limitations. This should be the answer David Sankel's concern too (above). I think there's lack of understanding of Phoenix here. At any rate, for the record: I am for supporting De Brujin style in Phoenix. The infrastructure is in place. I see no reason why we can't support both. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com