>> I 'm pretty sure that, while this clearly should be a function for
>> phoenix, I would not like the syntax:
>> g1(arg1,arg2,arg3,arg4)&&  g2(arg1,arg2,arg3,arg4).
>>
>
> Placeholders would be great here. I find most of the time I only care
> about EVT or EVT and FSM. Having MSM defined placeholders with cool
> names like evt_ and fsm_ wouldn't be bad IMHO.

These already exist but you are proving me that they aren't used to
their full potential now.


> Also... shouldn't operator() return a bool for a guard? Then this just
> becomes a composition. If g1 and g2 are phoenix functions then (making
> up some new MSM placeholders):
>
>          g1(evt_) && g2(evt_,fsm_)
>
>    will result in the composed lazy functors and placeholders are now
> your friends.

Nice!

> This also allows me to write full phoenix lambdas inline with the eUML
> which would be the cat's meow!

Yes, looks great! Actually, it would also be possible with today's
implementation, so that I don't know why I didn't do it yet. Shame on
me ;-)
I use this stuff for example in:
clear_(fsm_(m_src_container))

But I didn't think of generalizing this.

However, I'd still like to also have the possibility to write only g1
&& g2, treating g1 and g2 as terminals. The reason is that this way, I
am currently able to use the functor front end functors inside eUML,
which is quite nice. I'm pretty sure it'd be possible with phoenix too
and I'd avoid a regression.

> I like the way these discussions are going Christophe!
>
> michael

Me too! I have the hope the discussions on this list will deliver
something really cool.
Thanks for the great point!
Unfortunately, I didn't manage to get further on the first (blocking)
point yet :(

Thanks,
Christophe
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Reply via email to