Re: [boost] Re: review of proposed fsm library

From: Dave Gomboc (dave_at_[hidden])
Date: 2005-03-07 11:03:53

>  > The distinction made between state and state_machine, 
> which I  > consider to be unfortunate, was not justified in 
> the rationale...
> 
> There is at least one good reason - the library supports both 
> synchronous and asynchronous state machines, which are 
> essentially different beasts and are operated quite 
> differently. No such distinction exists for states, therefore 
> they shouldn't be treated the same way as state machines. 

However, asynchronous_state_machine is separated from both
state_machine and state.  Ergo, the reason must lie elsewhere.

I didn't delve deeply into the library's support for asynchronicity,
but I did consider it odd and amusing that at the level of hardware
circuitry, asynchronous behaviour is the default, and work is done
to get synchronous behaviour by adding latches and a clock, but that
for fsm (and many, many other software components rather
higher-level than a J-K flip-flop) the opposite was true.  I do
understand it, but I am not convinced that in this case it was the
correct decision.  Unforunately, I have to leave for work now. :-)

> Otherwise you would be able to mix both synchronous and 
> asynchronous states in one machine, which doesn't make sense.

While tangential to my original point about naturally recursive
structures, I'll take time out to disagree here too.  It _can_ make
sense to combine async and sync behaviour in different parts of a
state machine when one is modeling electrical circuits, e.g. in
certain regions of the circuit one may know that the behaviour is
sync and not want to spend extra CPU by going through all the async
motions.

Dave