Re: [boost] Template metaprogramming libraries

Subject: Re: [boost] Template metaprogramming libraries
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-09-16 23:37:59

On 9/17/2011 2:07 AM, Giovanni Piero Deretta wrote:
> On Fri, Sep 16, 2011 at 6:09 PM, David Sankel <camior_at_[hidden]> 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#lambda.unlambda
> 
> 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