[boost] De Brujin Bind and nested bind calls (was: Re: Template metaprogramming libraries)

Subject: [boost] De Brujin Bind and nested bind calls (was: Re: Template metaprogramming libraries)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-09-17 06:56:15

On Fri, Sep 16, 2011 at 7:09 PM, David Sankel <camior_at_[hidden]> wrote:
> On Fri, Sep 16, 2011 at 6:30 AM, Thomas Heller
> <thom.heller_at_[hidden]>wrote:
>> On Friday, September 16, 2011 06:17:00 AM David Sankel wrote:
>> > On Fri, Sep 16, 2011 at 4:51 AM, Thomas Heller
>> > <thom.heller_at_[hidden]>wrote:
>> > > On Thursday, September 15, 2011 12:31:50 PM David Sankel wrote:
>> > <snip>
>> > > <rant>
>> > <snip>
>> > > It should be noted though that phoenix users can get around
>> > > > this somewhat by using _identifier syntax.
>> > > > </rant>
>> > > #include <boost/phoenix.hpp>
>> > <snip>
>> > Â  Â auto flip = lambda(_a = _1)[bind(_a, _2, _1)];
>> > <snip>
>> > > Thanks for your unqualified rant, David.
>> > huh?
>>
>> Is this not what you were saying wasn't possible with phoenix?
>> Having a De Brujin style syntax is perfectly possible in phoenix. It just
>> hasn't been done yet cause, as you saw in my example, can be expressed by
>> using phoenix local variables.
>
> Oh, my bad. When I said "_identifier syntax", I was referring to phoenix
> local variables. I should have double-checked my phoenix vocab before I
> wrote.
>
> Phoenix locals definitely help fill the coverage problem I referred to. I
> don't know for sure, but I'd expect phoenix to cover all functions that can
> be defined in lambda calculus.
>
> 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.

Ok, misunderstanding on both sides, no offense intended.

> 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.

Now you got me interested, can you tell me how the DBB syntax solves
this problem? Or is it just that your particular implementation solves
it?

FWIW, phoenix provides everything to introspect the given F and decide
which action to take (wrap it into a lambda, "unlambda" it, leave it
alone, etc.). One of the main design goals of the phoenix bind module
was to be compatible to bind. So unlikely "bind" in its form will be
changed.

> Don't get me wrong, I think phoenix is an impressive feat. I'm just
> advocating that we stop perpetuating the troubles caused by basing new
> libraries on the traditional bind syntax.

P.S.: I also like the DBB style syntax and think it would be a great
addition, as JdG already mentioned, it is all implemented, what's
missing is the frontend.