[boost] Re: FSM Review

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-13 08:17:55

"Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> writes:

> I did consider that and tried to explain why I failed. I'm afraid that I 
> haven't been very successful in convincing people that the main 
> obstacles aren't easy to overcome.

I think some of us are unsympathetic to the "it's hard" argument ;-)
Maybe that's unfair, but it's the way it is.

>> It seems to me that if "orthogonal states" is the only feature in
>> conflict with getting the highest dispatching performance, it ought to
>> be possible to design a library whose performance only degrades if you
>> use that feature.
>
> I suppose you are inferring that from what I said in 
> http://tinyurl.com/7ybeq?
> I see that this can easily be misunderstood. Fact is that the current 
> interface *theoretically* allows for constant time dispatch, as long as 
> orthogonal states are not used. If they are used you get O(n) dispatch 
> where n is the number of currently active orthogonal regions. 

That seems close to optimal, considering the alternatives.

> However, there are a few practical problems for which I'll probably
> need help to overcome them.
>
>> But this library seems to have a design that's fundamentally
>> incompatible with an approach like that.  To get there, both the
>> interface and the implementation would have to be redesigned IIUC.
>> So that sums up why I think evolving toward support for lightweight
>> FSMs is not likely.
>
> See above, a few optimizations are theoretically possible but it is
> clear that the proposed FSM library will probably never earn itself
> the predicate lightweight.

I don't care if the library is lightweight (well I do a little).  I'm
talking about generating lightweight FSMs.  But I suspect that's what
you meant anyway.  That would confirm my impression.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com