Re: [boost] Re: FSM Review

From: Iain Hanson (Iain.Hanson_at_[hidden])
Date: 2005-03-15 06:15:07

Hi Dave,

I've taken the liberty of correcting my poor spelling in the quoted
parts of my message of last night. My only excuse is that it was late 
:-(. ( And I am a native English speaker :-( ).

On Mon, 2005-03-14 at 22:34 -0600, David B. Held wrote:
> Iain K. Hanson wrote:
> > [...]
> > There is no doubt ( in my mind ) that Andreas has done some very
> > good work. The issue is whether this library is suitable for
> > acceptance into boost. IIUC boost is predominately about best of
> > breed libs.
> 
> Yes.  And sometimes there is more than one best in the breed.

Agreed. We have a collection of containers to deal with genuine trade-
offs.

> 
> > The primary philosophy in C++ is you don't pay for what you don't use.
> 
> ...And yet, we have iostreams.

I don't know the history of iostreams or std::string but I'd be
surprised and a little disappointed if there flaws were known and yet
they were still admitted to the std. I know iostreams pre-dates the std
so perhaps its historical.

> > Andreas has deliberately taken a different approach. He has chosen
> > to go for the all singing, all dancing heavy weight approach.
> 
> ...Much like shared_ptr<>, which got into TR1.  And I dare say that
> shared_ptr<> is used in far more performance sensitive contexts than
> the FSM.  If we declared that shared_ptr<> is the end-all, be-all
> smart pointer for C++, I would be as unhappy as you are.

For very different reasons. shared_ptr deals with safety. The current
FSM proposal takes a feature like state specific storage and every user
has to pay for it whether they need it or not even if there is another
cheaper way to provide it. ( there always is ). 

> 
> > He has explained his approach on this list. You pay for State
> > Specific Storage whether you want it or not. You currently get
> > non-linear event dispatch ( without orthaganal regions ) if you
> > use outer states. And you get horrible performance on transitions
> > ( with loss of state specific storage when you transition out of
> > a state ).
> 
> And if that were a deal-breaker, people wouldn't be using the
> library, would they?  Apparently, there are applications where
> these are not the critical metrics, and people have already found
> use for it.

I'm sure its useful. Just as iostreams and std::string are useful. But I
don't think that std::string would get through a boost review if
presented for the first time today. And nor would it deserve to.

Associative containers have O ( log N ) performance for a number of
operations because of the underlying algorithm. The current FSM ( State
Chart ) proposal has its performance  characteristics because of the
choices made by the author not for any fundamental underlying reason.
All state charts can be collapsed to a STT.

> 
> > I know that if I hand write a GOF state pattern I can get close
> > to the scalability of the FSM lib but with constant time event
> > dispatch through a single indirection and can change state through
> > a single assignment.
> 
> But can you provide all the other features of the FSM proposal?  If
> not, then you're comparing apples to oranges, right?

Of course. At the end of the day, the most an FSM lib can give us is the
elimination of some boiler plate code. The doing away with cut and
paste. I think few will be willing to pay the performance price to do
away with boiler plate and cut & paste.

> > FSM is the domain but whether it is spelt STT or StateChart is
> > irrelevant one can be mechanically collapsed to the other. But
> > the fsm proposal does not do this. 
> > 
> > If we have a StateChart lib in boost it should scale as well as any
> > other library in boost
> 
> I'm not quite sure what you're saying here, but clearly there is
> precedent for solutions at different granularities/complexities
> /performance tradeoffs in Boost.  Consider tokenizer/regex/spirit.
> Consider compose/bind/lambda.  If you think that Boost needs a
> low-level FSM that concentrates on performance over abstraction,
> you may be right.  But if you think that it does not need an FSM
> library that focuses on abstraction and ease of use, it would
> appear that some users might disagree with you.
> 

I think that you are mistaking me. I strongly believe in solutions at
different granularities and the trade-offs that they require.

If this proposal was an just an std::map and presented as the containers
library then it would just need docs to be corrected to say that it is
part of a containers lib. ( Just as Andreas has agreed his proposal
should be spelt StateChart ).

My issue is that this is a std::vector with the performance and weight
of std::map. When we know this up front then *I believe* it is a good
reason to vote for rejection.

/ikh