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

Subject: Re: [boost] De Brujin Bind and nested bind calls (was: Re: Template metaprogramming libraries)
From: David Sankel (camior_at_[hidden])
Date: 2011-09-19 10:43:20

On Sat, Sep 17, 2011 at 6:56 AM, Thomas Heller
<thom.heller_at_[hidden]>wrote:

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

none taken :)

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

The DBB syntax itself solves the problem, or rather doesn't introduce it,
because every valid dbb expression has only one meaning whether it is used
in another dbb expression or passed to a function. In other words, dbb
expression are self contained. Whereas a valid traditional bind expression,
like bind( g, _1), could either be a function, that is equivalent to g, or
an unrelated piece to a bigger bind expression, bind( f, bind( g, _1 ) ).

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

The idea of adding DeBruijn indices to phoenix and letting the traditional
bind syntax recede into a historical artificial is interesting and
is consistent with C++'s own evolution philosophy. Hrm.

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

-- 
David Sankel
Sankel Software
www.sankelsoftware.com
585 617 4748 (Office)