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

From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-08-30 06:29:38

Andrey Semashev wrote:
> > The most important design decision seems to be let the state machine 
> > have a member of a class that derives from all states in StateList.
> > The switching between the states now changes which of these
> > "base classes" is "in charge" of handling events.
> >
> > I see two reasons for this design choice. The first is performance,
> > which is one of the main goals of the library, the second is that the
> > library models a "state machine" instead of a "finite state machine".
>
> Why? The machine is definitely finite, since it consists of finite
> number of states and defines finite number of transitions between them.

Other designs model 'states' as enums, while the fsm library models 'states' as classes. A 'state' modeled by an enum would be a "stateless state", while a 'state' modeled by a class can have "internal state". I'm quite sure that the "finite" in "finite state machine" refers to the number of "stateless states", because the Wikipedia article says: "A finite state machine is an abstract model of a machine with a primitive internal memory.". In other words, the resulting "machine" (created by "fsm::state_machine<...> machine") viewed as a black box is not guaranteed to only have a finite number of "stateless states", so it may exhibit behavior that is not possible for a finite state machine (like parsing a grammar that is too complex for a finite state machine)

I don't say that this is a bad thing. I just say that I guess this is one of the reasons why fsm models 'states' as classes and not just as enums.

> > The modeling of the "transition" concept could and should probably be improved.
> > The transition table where I can specify for given "intial states" and "events"
> > the resulting "final states" and "actions" (modeled as functions that take a const
> > reference to the corresponding event) to perform appears superior to me.
>
> You already can do that, as I've shown in my replies to David. The only
> difference with TMP approach is that there's no need to specify actions
> in the transition table. Is this what bothers you?

What bothers me is that although the important design decisions of the fsm library seem to be OK, it doesn't seem to please its potentials users.

But let's focus on this particular 'design flaw'. As I understand it, it's not true "that there's no need to specify actions". The actions need to be specified, not as entries in the transition table, but by overriding the "transit" method of the "fsm::transition<InitialState, Event, FinalState>" class. So I get the impression that I will have to create a new class for every transition, because this class will have to derive from the corresponding "fsm::transition<InitialState, Event, FinalState>" class, in order to be able to override the "transit" method. This seems to make to resulting code much more verbose (and difficult to read) than the resulting code for the TMP approach.

> > So in conclusion, most important design decisions are probably OK,
> > but the design as a whole is not finished and polished enough.
>
> Could you, please, elaborate which particular design flaws you are
> referring to?

I got the impression that the design was well thought out from a purely technical point of view. So you are able to tell a potential user how he can achieve a desired behavior with your fsm library. I noticed that the fsm library also seems to be able to emulate most other approaches quite well, from a purely technical point of view. However, the resulting client code often doesn't look beautiful. This is most striking for the "transition" concept. However, this also show up in other areas. The TMP approach uses enums to model states for example. I could emulate this by defining a state class template that takes the corresponding enum as template parameter. But the resulting client code will look clumsy.

However, the important point is that the code following the "// Concrete FSM implementation" line for the player.cpp and player2.cpp examples (which seem to be examples of the TMP approach) simply looks nice. So it would be more important to emulate this "looks nice" than to emulate any concrete technical tools (like enums or transition tables).

Note that I wasn't talking about design flaws, but about "not finished and polished enough". And that's what "looks nice" is all about.