Re: [boost] [review] FSM Second Call for Reviews

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2008-08-28 23:01:39

My review appears here with an attached cpp file implementing four 
approaches (not compiled): a manual nested switch/if function, the TMP 
book's mpl state table, boost.statechart, this FSM library.

> What is your evaluation of the implementation?
> Did you try to use the library? With what compiler? Did you have any
> problems?

Didn't download the library code, just read through docs and tried to 
implement a simple state machine comparing other approaches.

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

I think there are many applications for a lightweight, expressive FSM 
library in areas not typically using FSM's such as mouse event processing, 
filtering/transforming iterators,...

> What is your evaluation of the design?
> What is your evaluation of the documentation?

My view of the design is limited to what is described in the documentation. 
I was a little dismayed that some of the basic features that I needed are 
considered Advanced features such as sharing state and accessing the current 
state from outside the state machine. These are very easily accomplished in 
the TMP and StateChart libraries. The section on accessing state is not 
sufficient for me to determine which state the fsm is in between calls to 
process(). The data sharing approach between sibling states using a virtual 
base class is perplexing... there's no discussion of just what is the 
structure of the state machine. There is a lot of repititious boilerplate 
required relative to other libraries. There is a mixing of the transition 
"structure" in the procedural code which is better separated in the 
transition table approach. The FSM transition map may improve upon this, but 
I started getting lost in the description.

Documentation terminology drifts from the familiar "transition", "table",... 
introducing new terms "switch_to" and "transition map" without describing 
how/why they are different from the standard terms. The documentation seems 
to become less clear as the interface becomes more complex and verbose. The 
StateChart library addresses much of the same issues but always seems to 
remain comprehensible and keeps the reader grounded in familiar concepts 
while introducing new ones. I don't seem to be able to grasp the overall 
design concepts of FSM from it's documentation.

> How much effort did you put into your evaluation? A glance? A quick 
> reading?
> In-depth study?
> Are you knowledgeable about the problem domain?

I spent several hours reading the docs and putting together the attached 
example using the 4 different libraries/implementations applying them to a 
"paraphrased-from-an-in-production" use case. The state machines are used to 
iterate through an input stream of integers, extracting triplets of integers 
that are even or odd. Odd integers appearing within a even triplet are 
skipped, triplets of odd integers are extracted when they occur between even 
triplets. The transition table in the attached cpp file clearly depicts the 
UML state chart upon which the example is derived.

I've spent several years developing software that integrates 
Matlab/StateFlow generated code with hardware in the loop systems. So I'm 
familiar with many of the concepts.

> Do you think the library should be accepted as a Boost library?

No. I'd prefer that the performance and missing functionality be added to 
improve the existing StateChart library, and/or a true transition table 
approach be provided ala the TMP book's transition table. I dislike FSM's 
verbose interface along with it's procedural leaning paradigm.

Jeff