Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Darryl Green (darryl.green_at_[hidden])
Date: 2009-12-13 06:48:54

I'm out of time (not just the review period but other time constraints)
for doing a proper review, something I regret. However I would like to
vote for the acceptance of the msm backend conditional on:

Improvements to documentation to formally and fully describe the msm
interface.

Inclusion of straight-forward out of the box configurability to support
large FSMs.

Note that this is a vote for the back end (and the basic front Row<>
front end or a refinement of it only. I don't believe that euml,
promising as it is, should be accepted yet - but see discussion in reply
to Christophe below.
 

- What is your evaluation of the design?

The design is very well thought out overall. It seems (with a few
exceptions the author has expressed an intention to address) to be
capable of modeling all UML statechart concepts that I have used at
least. Being able to do so with a highly performant and scaleable fsm
"kernel" makes this library stand out from alternatives that are able to
offer either high performance or expressive power but not both.

- What is your evaluation of the implementation?

I only briefly examined it. It is very clear and concise. I did not
delve into the euml implementation.

  - What is your evaluation of the documentation?

It provides an adequate introduction, although this is made more
confusing than necessary due to the presentation of multiple interfaces
etc. The documentation as it stands is adequate for a review by being
expository of the library features and general concepts, but is
inadequate for a finished library. In particular, a precise reference
for the library interface would be very helpful and in my opinion a
necessity for acceptance.

  - What is your evaluation of the potential usefulness of the library?

I have found it to be usable for a realistically sized fsm (not using
euml). I am not 100% happy with some aspects of the interface (see reply
below) but it is adequate.

Yes, with gcc 4.2.4

  - Did you have any problems?

I couldn't get the euml examples to compile. I'm not sure whether this
is an environment problem (I was using boost 1.40 on Debian testing) or
something else. I didn't spend much time investigating.

  - How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

An unevenly in depth study. A quick look at the code. A few small
experiments. Played with the tutorials. Started implementing a (sketch
of) the itu Q.921 lapd protocol directly from the lapd state transition
tables in Q.921 as an experiment. Tried to sketch out enough of the
semantics as well as the states and transitions to be realistic. Only
covered a fraction of this but enough to convince me that the library is
adequately scalable for realistic problems. I would have like to spend
more time investigating how best to use the library but has been a
frantic time of year for me.
 
- Are you knowledgeable about the problem domain?

Reasonably. I've written fsms of varying complexity in a number of
languages in a number of problem domains, written simple fsm libraries,
and designed them in hardware.

The rest of this message covers some areas where I thing the genericity
of the library could be improved. However, I don't consider any of this
well developed enough to make acceptance conditional on anything in it. 

On Tue, 2009-12-08 at 11:59 +0100, Christophe Henry wrote:
> Hi Darryl,
> 
> I don't mind criticism, any of it, justified or not, as long as it
> doesn't stay vague and instead goes to concrete, argumented points.
> Vague negative comments bring little to the review and contribute to
> giving an incomfortable feeling to all participants.

I'm sorry my comments came across as negative. I only hoped to discuss
some (admittedly vague) ideas for refinement, not criticise.

My comments have been almost entirely around the back end and the more
direct front-ends to it. I personally think euml should be a separate
submission/review, once it is more "review ready". There seem to be
boost version and compiler version issues in getting even the examples
to compile. These are quite possibly outside of msm/euml itselfs
control, but if nothing else, they prevent easy review of euml.

I'm actually struggling with the above, because I think having euml in
trunk, with tests being run, could facilitate resolving some of these
issues. Maybe euml could be included as some experimental/example part
of msm initially?

The rest of my comments relate to the back end and the simpler fron
ends.

In general I like the proposed back end. My only "criticism" of it is
that it could perhaps be refined to contain only the bare minimum
necessary to express UML state machine concepts at the transition table
level, and to provide very abstract interfaces to extend it. Then this
back end kernel could be used to construct many styles of elaborated
FSM. This is the only thing behind my attempts to do away with state
objects containing entry/exit actions. Its just an idea, that I haven't
had time to develop further. There is nothing I outright can't do with
the existing design (except for the lack of in-state transitions, which
has already been raised and, iirc, you have offered to address).

> Constructive remarks are, on the other side, highly welcome! That's
> reason #1 for a review.
> I sometimes, like yesterday, take part in several parallel
> discussions, so I have little time left for remarks I cannot start
> anything with. Sorry about it, it's the negative side of the review.
> I'd be thankful if potentially useful but vague ideas were kept for a
> more quiet time.

I don't generally bombard innocent bystanders with my vague ideas. I
took asking for a review to be asking for it :-)

> >I genuinely don't see why msm needs to instantiate state objects it owns at all.
> 
> If this is the point, then it is a solvable problem. Clearly, it
> doesn't strictly need. It's just a feature, which is in some contexts
> very useful.
> The main one is to be able to save some data in the states. This data
> can then be generically accessed by the generic functors, thus
> increasing reuse and encouraging clean code.

I understand thats the idea. But I find, in the case of writing code
based on a protocol fsm, that the objects that implement the protocol
don't really reflect the state directly (at least not all the time).
They have rolse fairly orthogonal to the state.

>  The functor front-end
> will be your friend in this case. The same with eUML, but it doesn't
> have to be eUML.

In putting together the LAPD implementation I'm using the functor front
end, but end up creating functors via a few macros that dispatch to the
objects that do the work. I find they don't need access to anything
other than the fsm (to post events back to) and the event (to
access/process anything it contains). I'm fairly happy with that aspect
of the interface.

I haven't tried to do it yet, but it struck me that I could potentially
use the state types alone (not the object ref parameters) as tags to
determine which object to dispatch to. If I chose to have objects that
were 1:1 with states I could - but it wouldn't be part of the fsm
kernel. Is that concrete enough to make sense?
 
> 
> The second reason would be entry/exit:
> 
> >I suggest spelling them enter<state>(machine) and exit<state>(machine)
> > or machine.enter<state>() and machine.exit<state>().
> 
> Of course, this would be a solution. It's actually an interesting one,
> and if you don't mind, we'll keep for later (see below). Do we agree
> that it makes the machine slightly less readable?

No, I don't agree at all. I can't see how you can argue that having
transitions specified in states as statechart does is less clear than a
separate transition table, then claim that having enty/exit actions
specified in states is more clear than having them similarly separated.

 
> 
> The 3rd reason is state reuse. This brings us to:
> >What does reuse of a state in msm mean?
> 
> Interesting question, which is sadly ignored by many fsm frameworks. A
> case would be when you want to avoid doing the same case again and
> again. You could then define a state hierarchy, even (gulps) OO-like
> for this (or better some template policy magic). For example, I
> personally often add some logging in debug mode, so that I know what
> happened in my system. The visitor is another good example of it. I
> hope that after having a look at it, you'll see the interest you can
> gain from it.
> 

I personally find this response vague. Though you do propose something
concrete below. The visitor is clearly unnecessary if there is nothing
to visit. However msm should provide a way to "visit" the state types
rather than values. I think we are really arguing about whether the
type-value mapping should be in the back end or not. I claim not.

> You might have easily missed another case in the doc. If you have a
> look at iPodSearch and iPodSearchEuml, you'll see where I want to go
> next. To states which implement STL algorithms. You will then be able
> to write complex algorithms by simply moving some predefined states on
> a diagram. I plan to call it the STL (State Template Library ;-) ).

It is very hard to comment on this because I haven't seen the CASE tool
you propose and the description above and the examples isn't enough for
me to understand its scope and capabilities. It sounds really
interesting but I can't tell if I would find it compelling or not. And
compelling or not, I don't see that it would help with some problem
domains, such as the protocol implementation case I've been playing
with, but perhaps I'm not understanding your modeling tool proposal's
scope and metamodel. It isn't apparent to me that I am proposing
anything that prevents the tool you describe being implemented on the
modified back-end.

> While this is for the future, I'll need independent, reusable states
> for it.

But why do they need to be part of the transition table based "kernel"?
Don't pay for what you don't need/use?

> 
> >No. For the record, in my opinion, the single the worst feature of
> >statechart is the necessity to use custom reactions to implement some fsm
> <constructs. This was a subject of much discussion during the Statechart
> >(FSM) review iirc.
> 
> I see. Then I probably misunderstood your point.

Yes. Rather. Sorry for the combination of complex grammar and outright
incorrect grammar that would seem to have lead to this.

> 
> 
> > Can you perhaps explain why flags are needed?
> 
> Sure. If you look at the statechart doc, you'll see some state_cast. I
> personally find it not beautiful in my code. It's also hard to
> maintain when your fsm structure changes. Flags are faster, require no
> rtti, are more model-oriented as states define themselves their
> "property" and makes user code easier/smaller to read. It's even
> supported by eUML for better model-orientation.
> 

Ok. I understand the problem with the RTTI based approach. But once
again, I'm keen to take everything possible out of the states. I would
rather see a separate declaration of a set of states used to define a
"metastate" (a state analog with no in or out edges that is implicitly
entered when any of the states it "contains" is entered).

> I wanted to handle the entry/exit discussion separately. Hopefully I
> managed to convince you why states are useful and their instanciation
> brings some advantages.

I'm not outright against state instantiation. I can't be. I do really
like statechart's state instantiation model. However, in the review of
that library I did ask if there was any way that the costs associated
with it could be avoided when not strictly needed (when the state
contains no state-local storage). I'm asking a very similar question
here, but somewhat more emphatically because this is the Msm (first M is
important!) and it should surely be able to do this. Also, I think that
by avoiding state instantiation in the core of the back-end, it should
be easier to extend with *different* object instantiation models. I
would really like to see msm provide a back end with a good set of
interfaces to allow different state machine models to be implemented,
all benefiting from having at their core a highly performant library.

> Of course, there is a price to pay, though a small one (if without
> data, 1 byte/state). This is in most cases not a huge cost.
> 
> I agree there are cases where the price is still too expensive. I also
> agree, that the one current MSM back-end is not a solution for all
> problems, otherwise I would have written in stone that there is one
> backend and we'd be done. The MSM backend is a fully optimized
> machine, trying to pack as many features as possible at the lowest
> possible cost. There are however cases, where one would be ready to
> give up some features like state reuse and generic functors in
> exchange for reduced costs. For such cases, there is room for a
> mini-MSM backend (name from Barend Gehrels ;-) ). And in this case,
> your entry/exit solution appears a viable, interesting one for which I
> am thankful.

Ok. I'm just keen to see reuse of a common kernel, and separation of
what seem to me to be largely orthogonal domains. That may not be
practical. I am not a metaprogramming expert (nor a complete neophyte)
and haven't been able to spend much time on this very interesting
library, so I am quite possibly missing some very good implementation
reasons for not taking such an approach.

> 
> When preparing the review, I had several possibilities:
> - make the current MSM backend, with lots of features, thus proving
> that the approach of the MPL book was a great one.
> - make a reduced, smaller cost version, with the certainty of being
> criticized for not having enough features (see review from FSM) and
> rending a disservice to the book.

Personally, my criticism of (that) FSM was around an unconventional and
rigid fsm model. I could easily accept a library providing only a
simpler model on which more elaborate models/concepts can be built. I
hope msm can be that.

aside - it is very confusing that Statechart pre-review as called FSM as
well...

> - make a 3rd one, more dynamic, which I want to do since a while.
> - make no review until all possible back-ends are done and make
> everybody wait at least one more year.
> 
> Do we agree that solution 1 seems the more logical?

Logical from what perspective? Buying votes or producing a good library?
Politics... ;-)

Darryl.