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

Subject: Re: [boost] [review] FSM Second Call for Reviews
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-09-04 17:08:34

> It's not just for efficiency reasons, it's a consequence of my
> understanding of the FSM concept. I believe, the transitions should not
> be responsible for actually processing events, but instead should
> describe the state changes. While sometimes this is quite enough (e.g.
> in case of validators of different kinds), it is often needed to do
> other useful stuff on a certain event - IOW, to react on the event
> receipt. It is my belief that this is not what transitions are intended
> to do. That is why the proposed library is designed so that events
> eventually are processed in states (or put it another way, reactions on
> the events receipt are defined in states).

Because fsm will currently deliver events handled by transitions to the target state, it's more sort of a "transfer control to" than a "transition". This is probably a useful feature, especially for events that should always be handled by the same state, but it's not suited for a simple representation of a finite state machine in source code.

> However, I admit that there are possibilities that there is no need in
> reactions on events and the whole purpose of the state machine is to
> trace the transitions path, and the library is not perfectly suited for
> such use (although, it is still quite possible).

I don't think that the difference is the use case, but the representation in source code. I guess one possible representation of a finite state machine (one with a finite number of stateless states) is the list of transitions with the corresponding actions. (Let's forget about C++ for a moment. Let's simply imagine a text file with this list, and some tools to process this list in order to perform certain tasks, like optimizing the finite state machine, or verifying some important properties of the finite state machine.) Some people seem to think that this is a particularly clear representation of the corresponding machine. I'm no expert in this domain, so I can't say whether this judgment is justified. But my evaluation lead me to the conclusion that the "transition" feature of the fsm library is ill suited for a direct translation of this representation into source code.

> > But I get the
> > impression that you don't honor the advantages of the "incidence
> > list" representation enough.
> 
> I don't quite grasp what advantages these might be, with respect to the
> FSM concept and the proposed library in particular.

I don't have enough experience with the FSM concept to be able to judge whether the advantages offered by the "incidence list" representation are important in this domain or not. But they can be very useful in the domain of graph theory.