Proto for Boost mailing list page: Re: [proto] : Proto transform with state

Subject: Re: [proto] : Proto transform with state
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-11-18 03:58:17

Eric Niebler wrote:

> On 11/17/2010 2:18 PM, joel falcou wrote:
>> On 17/11/10 19:46, Eric Niebler wrote:
>>> See the attached code. I wish I had a better answer. It sure would be
>>> nice to generalize this for other times when new state needs to bubble
>>> up and back down.
>> 
>> Just chiming in. We had the exact same problem in quaff where needed to
>> carry on a process ID over the trasnform of parallel statement. If it can
>> make you worry less Eric, we ended with the exact same workaround.
> 
> There's another issue. Look here:
> 
>   // don't evaluate T at runtime, but default-construct
>   // an object of T's result type.
>   template<typename T>
>   struct type_of
>     : proto::make<proto::call<T> >
>   {};
> 
>   struct RenumberFun
>     : proto::fold<
>           _
>         , make_pair(fusion::vector0<>(), proto::_state)
>         , make_pair(
>               push_back(
>                   first(proto::_state)
> //----------------------1
>                 , first(Renumber(_, second(proto::_state)))
>               )
> //---------------------------2
>             , type_of<second(Renumber(_, second(proto::_state))) >
>           )
>       >
>   {};
> 
> Notice that the Renumber algorithm needs to be invoked twice with the
> same arguments. In this case, we can avoid the runtime overhead of the
> second invocation by just using the type information, but that's not
> always going to be the case. There doesn't seem to be a way around it,
> either.
> 
> I think Proto transforms need a "let" statement for storing intermediate
> results. Maybe something like this:
> 
>   struct RenumberFun
>     : proto::fold<
>           _
>         , make_pair(fusion::vector0<>(), proto::_state)
>         , let<
>               _a( Renumber(_, second(proto::_state))> )
>             , make_pair(
>                   push_back(
>                       first(proto::_state)
>                     , first(_a)
>                   )
>                 , type_of<second(_a) >
>               )
>           >
>       >
>   {};
> 
> I haven't a clue how this would be implemented.
> 
> It's fun to think about this stuff, but I wish it actually payed the
> bills.
>

WOW! A let statement this would indeed make proto even more awesome!
Let's see what we can do ;)

<hijacking the thread>
Btw, i just finished implementing the unpack feature we were talking about 
...
Short description:

Calling some_callable with the expression unpacked:
proto::when<proto::_, some_callable(unpack)>

Calling some_callable with an arbitrary sequence unpacked:
proto::when<proto::_, some_callable(unpack(some_fusion_seq())>

Calling some_callable with an arbitrary sequence unpacked, and apply a proto 
transform before:
proto::when<proto::_, some_callable(unpack(some_fusion_seq(), 
some_transform)>

Additionally it is possible to have arbitrary parameters before or after 
unpack. The implementation is located at:
http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/boost/phoenix/core/unpack.hpp

Just a whole mess of preprocessor generation ... this is not really fast to 
compile at the moment, PROTO_MAX_ARITY of 5 is fine, everything above will 
just blow the compiler :(