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. 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. 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. David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)