Re: [boost] De Bruijn Bind (alternate bind syntax) Interest?

4 Sep 2010

      On Fri, Sep 3, 2010 at 10:05 PM, Joel de Guzman
<joel@boost-consulting.com>wrote:
...
On 9/4/2010 9:29 AM, David Sankel wrote:
...
On Fri, Sep 3, 2010 at 7:46 PM, Joel de Guzman<joel@boost-consulting.com
...
wrote:
On 9/4/2010 5:42 AM, Dave Abrahams wrote:
...
On Fri, Sep 3, 2010 at 5:22 PM, David Sankel<camior@gmail.com>   wrote:
...
On Fri, Sep 3, 2010 at 4:46 PM, Dave Abrahams<dave@boostpro.com>
...
wrote:
On Fri, Sep 3, 2010 at 2:52 PM, Larry Evans<cppljevans@suddenlink.net
...
...
wrote:>   Since, as I mentioned, I had trouble understanding how apply
worked, and the code seems pretty complicated, at least to me,
> I was hoping DeBruijn's method would offer simplifications.
>
>
  From the examples I've seen so far, this would make it easier for
> bind
>
library writers at the expense of usability.  On th other hand, once
lambdas start to use protect() I'm usually giving up on them ;-)
Usability is hurt from whose perspective? The bind author or the bind
user?
The bind user
And how so?
...
1. It means learning a totally new paradigm for writing ordinary
lambdas that--so far--seems to require the grasp of quite a few concepts
that are not familiar to the average C++ programmer.  bind and its
cousins may not be as flexible, but they're designed to be intuitively
graspable (to a C++ programmer), and the paradigm is now going into
the standard so will be lingua franca.
2. Again, please correct me if I'm wrong about this, but it looks like
for "ordinary lambdas" (those that don't need protect), the
corresponding bind expressions are always shorter and simpler.
Perhaps it would be good to have a practical use-case. In a
lengthy discussions about scopes and higher order functions
(with Jaakko, Dave, Doug plus some more I don't recall), we
had this use case (this is the one you can see in the phoenix
docs here: http://tinyurl.com/295ha83):
write a lambda expression that accepts:
1. a 2-dimensional container (e.g. vector<vector<int>  >)
  2. a container element (e.g. int)
and pushes-back the element to each of the vector<int>.
The phoenix solution:
for_each(_1,
   lambda(_a = _2) // local _a captures the outer arg2
   [
       push_back(_1, _a)
   ]
 )
We once had outer. The outer solution looked like this:
for_each(_1,
   lambda
   [
       push_back(_1, outer(_2))
   ]
 )
How would that look like if you extend phoenix with your syntax?
Thanks for the example Joel.
Assuming for_eachF and push_backF are normal polymorphic functions, the
core would look like:
auto f = lam<2>( app( for_eachF
                    , _1_1
                    , lam( app( push_backF
                              , _1_1
                              , _2_1
                              )
                         )
                    )
               );
If we extend the language with for_each and push_back primitives,
auto for_each = appPrim( for_eachF );
auto push_back = appPrim( push_backF );
it gets a bit simpler:
auto f = lam<2>( for_each( _1_1
                         , lam( push_back( _1_1, _2_1 ) )
                         )
               );
If we do Stefan's multi-arity suggestion, which I still don't like too
much,
it looks like this:
auto f = for_each( _1_1
                 , lam( push_back( _1_1, _2_1 ) )
                 );
If we make _1 a synonym for _1_1 and so on (not saying we should), we get:
auto f = for_eachF( _1
                  , lam( push_back( _1, _2_1) )
                  );
Assuming phoenix::outer is reinstated, and assuming we have predefined
placeholders for the most common arities and scopes (e.g. 1..10 args
and 1..3 scopes), the phoenix equivalent would then be:
for_each(_1,
    lambda
    [
      push_back(_1, _2_1)
    ]
  )
Very close to your syntax.
Indeed we are converging. I like code that is made up of independently
useful and simple pieces that are composed together in powerful ways.

Your lambda uses brackets and I'm assuming this is for sequencing zero
argument procedures. So I'd make a separate function which would be useful
for that (Instead of brackets, I'd use normal function calls with variadic
templates for the same effect).

So

seq(a,b,c...) => { a(); b(); c();...}

lambda would be kept simple, as a single argument, and maybe a lamseq could
be

auto lamseq = lamAppPrim( seq );

And then we get a true equivalence:

  for_each(_1,
    lamseq
    (
      push_back(_1, _2_1)
    )
  )
...
It would be good to tackle this through practical use-cases
...
...
and using plain C++ terms. Too much formality hurts my brain.
If this use-case is too simplistic, then perhaps you can provide
something more elaborate, yet still practical.
I think your example is a valid use case. Unfortunately, I think it would
take longer to explain my particular use cases than the formality of this
syntax :/.
An example of a bind weakness that really bites is the following function.
This came up when I was making a high performance stream library:
//Where g is some other function
template<  typename F>
auto doThingee( F f )
    ->  decltype( boost::bind( g, f ) )
{
    return boost::bind( g, f );
}
doThingee does what you would expect most of the time. That is, until a
user
makes a call like:
doThingee( boost::bind( h, 22, _1) );
See the problem here? This is an example of the really crappy bind
semantics
that hardly anyone is aware of. With something like De Bruijn bind, there
are no surprises.
I don't think Phoenix has a problem with that. Just make
doThingee a phoenix::function or use phoenix::bind with
phoenix::lambda.
One thing's clear to me though: I have to reinstate 'outer' and
scoped_argument<ArgN, ScopeN> facility to make it easier.
E.g.
scoped_argument<2, 1> const _2_1 = scoped_argument<2, 1>;
(or something like that; I'm still confused with the indexing
used and seems to be mixing zero based and one based indexing.).
Why keep outer if you have scoped_argument?

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