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

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-01-24 03:12:11

----- Original Message ----- 
From: "David Abrahams" <dave_at_[hidden]>

> > This technique is adopted by Phoenix. With this, you can even do 
> > (as suggested by Joel Young):
> >
> >         -  \         \
> > double  -  /\  f .   /\   x.  f(f x)
> >         - /  \      /  \
> >
> > struct square_ {
> >
> >     template <typename X>
> >     struct result { typedef X type; };
> >
> >     template <typename X>
> >     X operator()(X x)
> >     {
> >         return x * x;
> >     }
> > };
> 
> This is similar to my "universal identity" suggestion from many months
> back.  However, "result" should be "apply" to make it an MPL
> metafunction class <wink>.
> 
> Hum, that result template looks like identity, and not square. Am I
> missing something?  I'd have thought:
> 
>     template <typename X>
>     struct result :  mpl::times<X,X> {};
> 
> > function<square_> square;
> >
> > template <typename F>
> > struct ffx {
> >
> >     template <typename X>
> >     struct result { typedef X type; };
> 
> Mighty confused.  Not
> 
>     template <typename X>
>     struct result :  mpl::apply<F, typename mpl::apply<F,X>::type> {};
> 
> ??
> 
> If not, what's the point of "result"?

result is the return type computer. In FC++ I think it's called Sig.
Thus, given some args T0, T1, it returns the resut of the operator().
Without it, the return type of the functor cannot be deduced 
(unless we have a typeof or auto). The Sig/result enables rank-2
polymorphic functoids (haskell/FC++ jargon).

> > PS> Jaakko and I are working on the LL/Phoenix merger.
> 
> Yay!  What about my tuples question?

How about a refresher? :-o

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