De Brujin Bind and nested bind calls (was: Re: Template metaprogramming libraries)
On Fri, Sep 16, 2011 at 7:09 PM, David Sankel <camior@gmail.com> wrote:
On Fri, Sep 16, 2011 at 6:30 AM, Thomas Heller <thom.heller@googlemail.com>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@googlemail.com>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.
On Sat, Sep 17, 2011 at 6:56 AM, Thomas Heller <thom.heller@googlemail.com>wrote:
On Fri, Sep 16, 2011 at 7:09 PM, David Sankel <camior@gmail.com> wrote:
On Fri, Sep 16, 2011 at 6:30 AM, Thomas Heller <thom.heller@googlemail.com>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@googlemail.com>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)
participants (2)
-
David Sankel -
Thomas Heller