Re: [boost] Re: state_machine

From: Scott Woods (scottw_at_[hidden])
Date: 2002-08-12 18:06:56

Hi Andreas,

Not 100% clear on what you were hoping for, but looked through your .zip and
have responded to content below :-) I'm certainly happy with your response -
think
I learnt more about boost and templates in 10mins looking through your code
than
I have for some time. Thanks.

----- Original Message -----
From: "Andreas Huber" <spam2002_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Monday, August 12, 2002 10:43 PM
Subject: [boost] Re: state_machine

> Hi Scott,
>
> > My general goal has been to create a coding environment that allows
> definition
> > of state machine code like below. This is in the belief that clarity of
> this code
> > has a pretty high priority.
>
> I intend to start a discussion about the requirements for a state-machine
> framework here at boost. However, before doing so I would like to put
> together a proof-of-concept framework, which supports most of the common
> features (full type-safety, entry-, exit- and transition-actions; guards;
> default transitions; composite states (also called sub-statecharts);

If I hear you properly then there may be a "boost::state_machine" (not a
naming proposal) in the future? If there is that kind of goal and you need
reviewers then I would certainly be interested.

Understand most of your feature list (and the code BTW). While most
of my development of state machines is informal, I have had some fairly
intense exposure to SDL (Specification and Description Language) and
much of the flavor (and specific primitives) of my "informal" state machines
reflects this background. Does your feature list reflect some similar
experience/standard?

> concurrent states; history). I think the discussion will be much more
> productive when there is actual code to tear apart ;o). To give you an
idea
> what I'm up to I attach the current version of the framework (an MSVC 7.0
> project).

Doh! Bit slow here (to upgrade) and 6.0 choked on (state.hpp:144);

      typedef my_context::is_context< context >::result result;

Code and example was clear enough for me to duck that wee task a while
longer (anyone else been bitten by the 7/MSDN upgrade hassle?).

A list of discussion points is tacked on below. Responding in full would
have
taken time+space and not really sure this is the place, or your intention. I
have
tried to use your vocab where possible but sometimes the overlap/intersect
was
not obvious.

It is quite possible that your requirements are different from the ones that
I
live with so please ignore points that are going off target ;-)

Ta,
Scott

* Relationship between protocols and machines
   An exchange of events (in SDL - signals) may be referred to as a
protocol. At
   least in telephony (and with the TCP-application-protocol-suite) the
state_machine
   does not own the protocol (e.g. class EvStart). This allows carefully
designed/proven
   interactions to be re-used. FTP may be deployed by many different
software systems
   and telephony signaling systems (e.g. ISDN Q series) are implemented in a
variety
   of vendor equipment.
* Physical separation of sender and transition implementation
   The software sending an event may be in a separate physical software
component
   to the transition code. The software that would send an SMTP "HELO" is
clearly
   separate from the software that would perform the process_event().
* class Active versus state_machine::initial( int event )
   Essentially you have a more sophisticated architecture here. All sorts of
pros/cons
   involved. Did you have the "sledge-hammer" reason for transition classes?
* Threads and state_machines
   Not clear what your directions were in this area. Event or signal
processing is
   an inherently async activity so I'm assuming that this nastie must be
tackled
 . Your example was (thankfully) single-threaded but maybe you have thoughts
   here?