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

Subject: Re: [boost] De Bruijn Bind (alternate bind syntax) Interest?
From: Smith, Jacob N (jacob.n.smith_at_[hidden])
Date: 2010-09-07 13:24:47

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-
> bounces_at_[hidden]] On Behalf Of Joel de Guzman
> Sent: Friday, September 03, 2010 8:14 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] De Bruijn Bind (alternate bind syntax) Interest?
> 
> On 9/4/2010 10:40 AM, David Sankel wrote:
> 
> >> 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.
> 
> Yep. That's the mantra of Phoenix.
> 
> > Your lambda uses brackets and I'm assuming this is for sequencing
> zero
> > argument procedures.
> 
> Yeah. It's use and syntax is historical. The intent is to be as close
> as possible to C++ and to somehow emulate C++ statements. It is
> used that way, e.g.:
> 
>    if_(c)
>    [
>      dothis()
>    ]
>    .else_
>    [
>      dothat()
>    ]

If we're talking C++0x you could also use initializer-list constructors:

auto con = if_( c ), then_
           {
              dothis0(),
              dothis1(),
              dothis2()
           },
           else_
           {
              dothat0(),
              dothat1(),
              dothat2()
           };

For an Adam/Eve DSEL in C++ we used this syntax:

sheet save_file =
  "save_file" == sheet
    {
       interface == section
       {
         var{"file_name"} == [](arg_map args){ return any(""); },
         var{"file_type"} == "txt",
         (var{"password"} <= (var{"file_type"}, var{"password1"})) ==
             [](arg_map args)
             {
               return args.get<string>("file_type") == "txt" ? any("") : args["password1"];
             }
         // more constraints
       },
       output == section
       {
         // more constraints
       },
       invariant == section
       {
         // more constraints
       }
    };

Which is assuredly overkill for a DBB, but still an option for syntax. BTW, initializer lists work great for an inline JSON library, i.e.,

json myjson =
  dict
  {
    key{"foo"} == list
                  [
                   "baz",
                   "bif",
                    list
                    [
                     "bop",
                     "quux"
                    ],
    key{"baz"} == "bar"
  };

> It's not only for the sake of being clever. More importantly, C++ users
> connect to this easily compared to other concocted means. It is
> instantly
> recognizable.
> 
> > 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)
> >      )
> >    )
> >
> >
> > Why keep outer if you have scoped_argument?
> 
> Agreed. outer is(was) built on top of scoped_argument anyway.
> 
> Regards
> --
> Joel de Guzman
> http://www.boostpro.com
> http://spirit.sf.net
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost