[boost] [fsm review] Not quite a review

From: Darryl Green (darryl.green_at_[hidden])
Date: 2008-08-19 06:50:42

I don't know if I will have time to do a proper review of the library.
The following are my notes on it so far.

I've read the documentation for the libary, but haven't tried to use it.

Good points:

Simple.

Relatively fast at runtime.

Docs are quite good, but perhaps lack enough rationale style
documentation on how the library models FSM concepts. Would benefit from
some "how to" examples of more realistic usage and some "how to" docs on
translating FSMs expressed using UML (or Harel) statecharts into a form
implementable using FSM.

Bad points:

Unusual terminology. While there are obvious performance reasons for
avoiding the Boost Statechart approach of applying an RAII model to
state activation, it is not clear why at least basic concepts and
terminology have not been used in FSM - especially as most Statechart
terminology and FSM behavioural concepts are straight from UML
terminology (it is a standard, you could pick another one, but why not
stick with this one)? Note that this is *not* a request that the library
include more features - just for some consistent ones.

Some idiosyncratic behaviour. The FSM delivers the event to the
on_process() handler in the "switched to" state when the transition is
specified using the transition map, while delivering it to the
on_process() handler in the current state if no transition map entry
matches. There are warnings against mixing the transition map and
switch_to() approaches to FSM specification, but even so it seems that
the 2 uses of the on_process() handler are completely different. Would
it not be better to have a model similar to Boost.Statechart where a
custom reaction (implemented by a react() method) in a state is used to
perform actions within the start state, generally including making a
(gated) transition, while any action to occur on a transition is
specified as part of the transition? Further, that transition action
should be performed after the exit action of the current state and
before the entry action of the new state.

No event queuing mechanism, so no way to post an event while processing
an event - although I see there has been some discussion about adding
event deferral - which might be (almost) enough.

Slow at compile time. I have not tested as yet, but if it is as slow as
the mpl example state machine implementation, this will be a problem (I
have previously had to abandon use of the MPL FSM due to compilation
time issues on only moderately complex FSMs).

Lacks real world use? I don't know if that is true, but I haven't seen
anything other than toy examples. I was thinking that in the cases where
the performance of Statechart was inadequate for complex augumented FSM
implementation I would consider using FSM - but it would mean building a
fair bit of additional scaffolding around FSM - maybe this should be
part of the library? Or at least some examples of ideomatic use should
be included? I found myself wondering if anyone had actually tried to
use it in this way? Conversely, I don't find it compelling for
implementing something like a lexer or even the terminal emulator
example. What is the application domain?

Not quite a conclusion:

This is a hard one. At one extreme, Boost.Statechart is extremely
powerful and well worth using in certain application domains (but there
are performance implications), and at the other, as has been
illustrated, various hand-rolled solutions of varying degrees of
elegance get the job done. There seems to be a lot of space in between,
and I'm not sure that the proposed FSM library fills enough of it.