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

Subject: Re: [boost] [review] FSM Second Call for Reviews
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-09-03 17:43:39

Thomas Klimpel wrote:

> I don't think that transitions should have internal state. But I
> think that the user should have the possibility to model them
> explicitly. And this includes associating an action to them.

You can. However, not everyone liked the exact syntax the library
provides in order to do that.

> This paragraph was more about Dave's statement "To start with,
> "states handle events" is not part of the abstraction of what an FSM
> is." and your reaction to it. Because I'm more familiar with graphs
> than with finite state machines, it's easier for me to think in terms
> of graphs.
> 
> One of my thoughts is: "Why not? The "adjacency list" is a valid
> description of a graph, just as the "incidence list" is." But on the
> other hand, you insist to deliver each event to a state, so you
> somehow take the "states handle events" to the extreme. I understand
> that you prefer the "states handle events", because the "adjacency
> list" is the more efficient representation of the two.

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).

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'm not sure if this is
a significant flaw, since I, for one, have not yet encountered such a
case through my experience and I can't tell how common it is.

> 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 agree that in
graph theory it might be very useful to embed data and meta-data (I
guess, this is what you meant with "additional information") into graph
edges. We both agreed that FSM transitions should not contain any data,
which leaves meta-data on the table. Such meta-data may, indeed, be
useful sometimes, however, I wouldn't say it is common.

FWIW, this kind of information can be described with transition table
entries (more precisely, their types and behavior) and thus is supported
by the library. Since users can define their own transition rules and
put them into the transition table, it is possible to embed any kind of
information as long as it is possible in C++.

However, I am not a specialist in graph theory and may well be missing
something obvious. Am I?

> Each "edge" or "transition" is simply a row in a table or list.
> Associating additional information is as easy as adding an additional
> column to the table. It seems like all we need to associate with a
> "transition" for a finite state machine is an action, but I'm no
> expert for finite state machine.

This part leads back to syntax issues. Well, I've already expressed my
motivation for the chosen approach (for simplifying transition handlers
overloading and templating), but, as I can see, this motivation is not
considered significant enough by most of the reviewers. In that case I
will change the transition handler specification syntax to be more close
to the TMP approach.