[boost] [fsm] Your 2 cents

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-09-03 15:07:24

Thomas Xkey wrote:
> fsm
>
> This library seems & acts more like a "simulator" than an
> "efficient finite state machine".

Please define "simulator" and "efficient finite state machine".

> There is a very high level functionality tied into
> (possibly) a bare-bones base... not properly tiered or
> layered approach.

I believe the non-layered approach is a more or less obvious result of 
the requirements defined in the rationale. If you agree with this 
statement then please say exactly which requirements you have a problem 
with. If you don't agree I'd be happy to hear your proposal how to make 
boost::fsm more layered and how this layering introduces advantages 
compared to the current design.

> It doesn't seem to scale well even according to the
> author(s)?
> (most fsms a computer scientist would deal with encompass
> 100s to 1000s of states with
> as many different transitions possible)

Please say where in the docs you think I say that it doesn't scale well.

> I would strongly urge something more efficient and bare
> bones along the lines of
> http://www.research.att.com/sw/tools/fsm/

Unless I'm mistaken, this is a dynamically configurable fsm. For the 
reasons explained in the rationale boost::fsm is a static fsm. I don't 
think these two FSM variants can be compared in a meaningful way.

> take on the mantle of an "fsm" library in boost upon which
> coarse-grained objects can be simulated from
> above.

You seem to imply that boost::fsm is going to be *the* boost state 
machine libraray forever (given that it is accepted). I don't think so. 
boost::fsm does not offer top-notch performance and never will (I don't 
think it is particularily slow either). boost::fsm is more geared 
towards projects that need to quickly implement large and complex FSMs 
drawing on all UML features. I acknowledge that boost::fsm *can* be the 
wrong choice for some projects and I'm therefore not at all surprised if 
another static fsm library with a different focus (e.g. along the lines 
of the MPL FSM) will make it into boost in the not too distant future.
I strongly believe that a single best FSM implementation does not exist. 
The problem domain is just too complex.

> would prefer this 'currently proposed' fsm to take on its
> true stance perhaps attaching the nomenclature
> of "hlfsm" --> "high level fsm".

I don't like hlfsm, but am otherwise open to suggestions for a better 
name (I agree that boost::fsm isn't the best possible name).

>  Due to its greater
> abstractions, fluffy aggregations

What do you mean with "fluffy aggregations"?

> and bulk in nature
> it isnt "efficient".
> If a library isnt efficient for its purpose or intended
> purposes then it will be under-utilized.

What do you think is the intended purpose of this library?

> I could never use this one
> as it is evolving away from an efficient
> fsm into more of a large coarse simulator. [now if i had
> need of that it would be great]

What do you use FSMs for?

> Can we adjust this library conceptually into a cleaner
> bare-bones fsm at one layer

As I said earlier: I'll happily consider your proposal on how to do so.

> and then interject the higher level simulation aspects
> along with the ability to
> automatically produce code etc.

No, this will not happen. One of the goals of boost::fsm was to get rid 
of the code generation step. I strongly believe that code generation in 
the FSM domain typically introduces more problems than it solves. Quite 
a few people argue otherwise and if this means that my library is not 
accepted then I will take it elsewhere.

> [Canned automatically generated code is usually not so hot.

For good reasons.

> In fact it rather bites. Any decent programmer can still
> out-optimize todays compilers based on
> intimate knowledge of their code & algorithms even on
> todays complex processors.
> Given that compilers have thousands of man-years of code &
> know-how how does one expect this fsm library
> to generate decent code or is it intended for someone who
> cannot program?]

Please define what you mean with "decent code". Again, a library that is 
"decent" in one situation might be bad choice in another. Usability was 
and always will be the topmost priority for boost::fsm. Yes, this means 
that the library will never offer top-notch dispatch speed or ultra-low 
memory footprint. Many projects using FSMs can easily trade some of 
theoretically possible performance for more important things like faster 
development. At least a few people seem to agree (TMK, there currently 
are 3 real-world projects using boost::fsm with at least some success).

Regards,

Andreas