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

From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-09-02 18:49:12

Andrey Semashev wrote:
> > Your answers confirm my initial statement: "The modeling of the
> > "transition" concept could and should probably be improved."
>
> I'm just trying to understand how, exactly, it should be improved. Your
> previous posts were referring to the necessity to override transit
> handlers in order to define transition actions. I confirmed that but
> added that it is not worse than other solutions mentioned. So, I don't
> see how and why this particular feature should be improved.

OK, maybe the purpose of this particular feature was different from what I thought. So I will change my statement to:

The library should provide true support for the "transition" concept.

I tried to explain why I think this is important. If you ask me, "how" this should be done, all I can say is that the TMP approach seems to look nice from the user perspective (disregarding compile times).

> > Also, your statement "you get precisely what the TMP solution
> > provides" is misleading. It's easiest for me to explain this with an
> > example from graph theory. A graph can be described by an "adjacency
> > list", but it can also be described by an "incidence list". The
> > state-based approach of the FSM library corresponds to the
> > description of a graph by the "adjacency list". The transition-based
> > approach of the TMP solution corresponds to the "incidence list". The
> > description by an "adjacency list" will often be more efficient than
> > the description by an "incidence list", but the "incidence list"
> > makes it easy to associate additional information to the edges of the
> > graph. You basically claim that you also support the "incidence list"
> > approach, but you don't provide support for associating additional
> > information to the edges of the graph, because you consider this "too
> > complex".
>
> Yes, however, I'd rather say, it would be difficult to use an FSM with
> transitions that have internal states, while simplicity being one of the
> primary goals of the library.

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.

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. But I get the impression that you don't honor the advantages of the "incidence list" representation enough.

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. Maybe somebody would also want to associate a probability with a "transition", or a time interval, or ???. For graphs, I know that it is common that one has to associate a bunch of additional information to the edges.