Re: [boost] Re: MPL usage for code generation

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-01-24 20:56:10

----- Original Message ----- 
From: "Aleksey Gurtovoy" <agurtovoy_at_[hidden]>

> Joel de Guzman wrote:
> > Here's the Phoenix version:
> > 
> >     struct my_function_
> >     {
> > 
> >         template <typename Arg1T, typename Arg2T>
> >         struct result { typedef void type; };
> > 
> >         template< typename U >
> >         void operator()(std::string const& text, U)
> >         {
> >             // ...
> >         }
> > 
> >     };
> > 
> >     function<my_function_> my_function; // here!
> > 
> > Then:
> > 
> >     mpl::for_each< my_types >(my_function(text, _1));
> 
> This is way too cool! Now we only need to provide such free-standing forms
> of all STL algorithms/member functions, and we will be living in a different
> world:
> 
>     std::vector<std::string> v;
> 
>     push_back(v, "text"); // plain call    
>     for_each(input, push_back(v, _1)); // currying
>     for_each(v, for_each(_1, print_char)); // more currying
>     // etc.!
> 
> Breathtaking, IMO.

That was my intent. Well, as Peter noted, there's a problem
with ambiguity. Obviously, there's the namespace solution.
Once the function<ftor> feature will be incorporated into
LL, the curried form can be written easily as ll::for_each.

This feature has been with Phoenix since its inception. That's
why I requested people to look deeper than the cute if_[] syntax
when Phoenix was first introduced. The library is really so much 
more than that.

The next step (hopefully soon) is to have the ability to wrap 
classes easily so as to provide member functions in curried form,
so we can write:

    for_each(c.begin(), c.end(), obj.print(_1));

Then, well can really live in a curried world.

Joel de Guzman
joel_at_[hidden]
http://www.boost-consulting.com