Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2016-02-02 16:29:35
On Tue, Feb 2, 2016 at 7:09 PM, Klaim - JoÃ«l Lamotte <mjklaim_at_[hidden]>
> On 2 February 2016 at 19:41, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
> > I see that MSM eUML defines the transitions like
> > target == source + event [guard] / action
> > but MSM-lite reverse the source and target
> > src_state == dst_state + event[ guard ] / action This is confusing.
> > Why have you chosen this syntax? Vicente
> Same question here. I misread the examples at first because the meaning is
> It feels unnatural that the state you are going to is part of the
> expression stating the conditions to get there.
> The MSM syntax is clearer to me at least.
I see your point. It seems like I will have to change the default behaviour
then as it's clearer for most devs. Guess, I'm the ackward one here.
Please, check the euML emulation example ->
behaviour might be changed if it comes to states order by defining
If it comes to the transition table DSL. I was concidering a lot of
options. For example MSM3(eUML2) is using src + event [guard] / action ->
which looks great, however, having a dst state at the end is not really
practical, especially after a lot of noice introduced by guard and actions
(for example in place lambda expressions).
Right now, I'm thinking of introducing DSL which would look like that.
"idle* -> state1"_t + event [ guard ] / action
, "state1 -> X"_t [ guard ] / action
Nevertheless, I'm not sure whether such approach would be seen positively
because following MSM approach it should be more like that.
"state1 <- idle*"_t + event [ guard ] / action
, "X <- state1"_t [ guard ] / action
which looks confusing for me. Any thought on this?
Thanks for your feedback,
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk