[boost] [review] FSM Library review result

Subject: [boost] [review] FSM Library review result
From: Martin Vuille (martin_at_[hidden])
Date: 2008-09-15 11:24:10

This is a summary of the comments received during the
review of Andrey Semashev's Finite State Machines (FSM)
library. Apologies for the delay in getting these out.

DOCUMENTATION

* Relocate ToC to make it stand out.
* Several people used the Wikipedia article
  http://en.wikipedia.org/wiki/Finite_state_machine as
  a reference for FSM terminology and operation, and
  found discrepancies between Boost.FSM and that description.
  Perhaps Boost.FSM should explicitly describe its FSM
  metamodel, or refer to an existing metamodel (Wikipedia
  FSM or Harel or UML Statechart, for example). The latter
  was mentioned several times as being preferred since it
  is a standard.
* If possible, use standard terminology. For example,
  "transition map" vs. "state transition table". Or
  define the non-standard terms.
* Include a comprehensive rationale mapping the design
  choices to the design objectives.
* Compare/contrast Boost.FSM with the FSM implementation
  as described in "C++ Template Metaprogramming".
* Add an example of event deferral using boost::function.
* Clarify support for multithreading vs. asynchronous FSM,
  as some were confused by existing text.
* Clarify lifetime of objects.
* Add implementation of example using transition map/STT.
* Add more complex example(s).

SCOPE/FEATURES

These were features that were suggested or asked about.
Some or all may not be suited for addition to the library.
In that event, it may be useful to explicitly mention in
the documentation that they are not supported, and why.

* Support nested states. Return-to-history was cited as
  an example of a benefit of nested states over nested FSM.
* In STT, support matching "any" from state.
* Add syntactic sugar to support "synthetic" states (cf.
  http://lists.boost.org/Archives/boost/2008/08/140714.php)
* Support event deferral.
* Support data-dependent transitions (perhaps this is the
  same as the synthetic state suggestion above).
* Improve modeling of the "transition" concept. Specifically,
  there was an issue with the fact that the action was
  associated with a state rather than a transition.

INTERFACE

* There was a lot of discussion comparing the amount of code
  required to implement an "ad hoc" FSM, vs. the amount of
  code required to implement the same FSM using Boost.FSM.
* The "transition map" representation was deemed to contain
  too much syntactic noise and not sufficiently similar to
  a traditional STT, and it was suggested that it should
  include the transition action.
* Some felt that the interface was too procedural rather than
  being declarative.

IMPLEMENTATION

* There was quite a bit of discussion of the Boost.FSM
  implementation vs. the C++TM implementation, but I don't
  believe there were any specific conclusions reached.
* Handling of event is different depending on whether or not
  transition map is used (handled by "to" state vs. current
  state, respectively). This is also the case when an event
  is not found in the transition map. This could lead to
  errors.

Thanks again to Andrey for his submission and to all the
reviewers and other who made comments for their input.

MV