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