>     > Software types are likely to cheat and cause their code to break by doin
g
>     > things only when a state is entered or exitted.
>
>     AS as "software type", I usually create three states in such cases: One
>     for the "entry" state, one for "polling, looping, etc", and one for the
>     "exit" state.
>
> Yep.  That'd be the "pure" state machine...
>
>
>     I don't know if *this* is cheating or not, but sometimes the next state
>     to be transitioned to from the current state depends on the previous
>     state.
>
> That's cheating too.  Actually, it sounds like a particular case of
> entry cheating (steady state means that the previous state is the
> current state, right?  So special state entry code is the same as being
> dependent on the previous state...)

It's not cheating at all.  It's merely a "substate" of another state.
If you'd prefer to represent this as a "top level" state it can be
done by breaking this "super state" into "top level" states for each
set of prior and next states.

In hardware this is almost a necessity unless you're using a HDL.  All
software is a state machine, running on a state machine which is
comprised of a whole bunch of other state machines.  It's sort of silly
to try and say that one style of coding is a state machine and another
isn't when every statement affects state regardless.

Even in hardware there's a bunch of different models for constructing
and defining state machines.  They're just styles of state machines, not
the whole class of them.

It just depends on how explicit or implicit the model is.

Chris