Some more infos to get ideas straight. Given a pool of user defined functions or functor, I'll be able to write code like : run( seq<Foo>() | seq<Bar>() ); and have this code generate a parallel pipeline using MPI. To do so, I define a semantic rule for each parallel construction (called skeleton) that turns a sub-expression into a process network. A process_network is a static datatype defined by a triplet where : - P : a list of processus - I : a list of input nodes - O : a list of outputs node All those 'list' are in fact mpl::vector of types OR mpl::long_<> process_network code is roughly this : template struct process_network { typedef P process; typedef I inputs; typedef O outputs; typedef typename bm::size<process>::type cardinal; static inline void run(); }; So P helds a list of process. A process is formally defined by : - the processus unique PID; the processus descriptor.</li> - a descriptor which is a list of "macro-instructions" for the processus to perform at runtime. template struct processus { typedef ID pid; typedef DESC descriptor; typedef processus type; typedef typename descriptor::type code; static inline void run(); }; Finally, the descriptor is formally defined by : - a lis of PID of preceding processus - a list of PID of following processus - a list of macro-instructions template struct descriptor { typedef IPID i_pids; typedef OPID o_pids; typedef CODE macro; }; Supported skeletons are : pipeline (operator|) parallel execution (operator&) farming which si tied to a special function called farm adn used like : farm<N>( some skeleton expression ) All of these have to be built from the expression above. To do so I have a set of rules. A rules take 2 process network and do stuff with its processus liss. For example, pipeline two process network concatenates the list of processus, add a Send macro instructions to all 'outputs' processus and a Receive macro instructions to all 'inputs' processus. Finally, the global out/input of the new network is set accordingly. Currently, I do the following (and yes it is ugly) : template struct apply_rule< bp::exprtag::bitwise_or,X,2, ID > { typedef exprtag::bitwise_and,X,2 base; typedef typename result_of::arg_c::type::expr arg1; typedef typename result_of::arg_c::type::expr arg2; typedef typename apply_rule::type pn1; typedef typename apply_rule::pid next_pid; typedef typename apply_rule::type pn2; typedef typename apply_rule::pid pid; typedef typename rule_seq::type type; }; basically, i extarct the arguments of a proto expression, evaluates each child of the expression to get their respective process_network,retrieves the next available PID and apply the corresponding rule to those intermediate result. Doing so works well for all my rules even in complex cases. When using proto transform and fold_tree, it doesn't. In fact, it even looks like the next PID and temporary network are badly computed, thus leading me to thinks that I badly use state and such. -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France

Eric Niebler a écrit :

I'm starting to get the idea, but I'm a little dense. And you've only shown a fragment of the kind of transformation you're doing. Since you have (ugly) code that already does what you want to do, can you post it so I can clearly see what you're doing? I can try to find a cleaner solution for you.

Here is two zip files of the current state of work. Should compile with boost 1.35 + proto. If MPI inclusion is a problem just remove them altogetehr, they're not compelte yet. http://www.ief.u-psud.fr/~falcou/cpp/niebler/nice_not_working.zip http://www.ief.u-psud.fr/~falcou/cpp/niebler/ugly_working.zip Tell me when they're downloaded so i can remove them ;) First is what I tried to do using transform but failed to work properly. Second one works as intended by my semantic but is "ugly" (aka explicit use of inner form of proto:::expr). The use-case that fails is the followiong : cout << probe( (seq<Foo>() & seq<Foo>()) | (seq<Foo>() & seq<Foo>())); it supposed to write something like [0] : Function call send to 2 [1] : Function call send to 3 [2] : Recv from 0 Function call [3] : Recv from 1 Function call But in fact it outputs : [0] : Function call [1] : Function call [0] : Function call send to 2 [1] : Function call send to 3 [2] : Recv from 0 Function call [3] : Recv from 1 Function call