Re: [boost] [review] Fusion review, finalization

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-05-12 18:47:12

Joel de Guzman wrote:
> Tobias Schwinger wrote:
> 
> 
>>2. Fusion and MPL placeholder expressions
>> 
>>   MPL placeholder expressions are very convenient for specifying the result
>>   because of their lazy nature (see lines 267, 312). Of course, this approach
>>   trades compile time for syntactic sugar. The syntactic sugar might not be 
>>   entirely irrelevant, because it allows us to emphasize even complex problems 
>>   with little code. 
> 
> 
> Sure.
> 
> 
>>   So, I still wonder, whether it is a good idea to use MPL lambda for the
>>   result computation or not. Is it?
> 
> 
> I think so, yes.
> 
> 
>>   If so (even occasionanlly), it would be necessary to have at least accessors 
>>   for pair members (they are needed to keep the evaluation lazy, see line 211) 
>>   or, ideally, if there would be a normalization between the STL and the MPL 
>>   pair concepts (then MPL's accessors, 'first' and 'second', could be borrowed).
> 
> 
> If my suggestion to make mpl/fusion pair fully conforming mpl/fusion
> sequences is accepted, then you can use code like mpl::begin<_> or
> mpl::at<_, N>.
> 

It's a very cool suggestion, IMO (just for the protocol: seems 'mpl::begin' was 
supposed to read 'mpl::front').

But it seems we're still talking about different pairs of shoes (shoes of pairs?):

Given the (actually) unspecified type members of 'mpl::pair' get "_type"-suffixes, any pair would just work with MPL *as a pair*. That is, the 'first' and 'second' metafunctions are trivial and (unlike all sequence-stuff) not tag-dispatched, so their instantiation is very lightweight and especially nice for within iteration...

> 
>>   (It would also be cool if one could just typedef the lambda expression to nested 
>>   result or inherit from a wrapper. I don't know whether it's possible and a good 
>>   idea - this part is just loud thinking)...
> 
> 
> Hmmm... can you elaborate. I lost you here.
> 

OK. I believe it works best with some imaginary code:

// rtc stands for runtime code
// rmf stands for result metafunctions

   struct a_func
     : result< munch< _1, tweak<_2> > >
   {
      template<typename A, typename B>
      typename result<A,B>::type operator()(A const & a, B const & b) const
      { 
        return rtc::munch(a,rtc::tweak(b)); 
      }
   };

-------------

   namespace rmf
   {
      typedef result<  munch<_1,tweak<_2> >  >  a_func;
   }

   namespace rtc
   {
      struct a_func
        : rmf:: a_func
      {
         template<typename A, typename B>
         typename result<A,B>::type operator()(A const & a, B const & b) const
         {
            return munch(a,tweak(b));
         }
      };
   }

Regards,

Tobias