On Sun, 2008-08-17 at 22:12 -0800, David Abrahams wrote:
on Sun Aug 17 2008, Darryl Green <darryl.green-AT-aanet.com.au> wrote:
the diagram in the USB example is an incredibly verbose representation (by count of nodes and edges) of what is described by Phils code.
But Phil didn't encode the whole machine represented in the diagram.
No - but most of what he left out was checking for invalid inputs that you have been claiming is not necessarily required. Adding in the suspended state tracking in an ad-hoc way would only need: bool suspended; void bus_inactive() { suspended = true; } void bus_activity() { suspended = false; } A simple "flat" state diagram and a similarly simple state transition table are always going to be very verbose.
Obviously you don't infer from this that any attempt to embed state diagram (like) representations in code is pointless,
I do think it's pointless in C++, although I don't do it by inference from anything you're mentioning.
Wow! Does that mean you are against any FSM library or only one that tries to represent a diagram by some method other than an attributed edge list (state trainstion table)?
"states handle events" is not part of the abstraction of what an FSM is. Look it up in Wikipedia or any CS text. You won't see any such description. Instead, that's a point-of-view unnecessarily imposed by the proposed library. So the library's DSL isn't a faithful reflection of the ways we already talk about FSMs.
Ok - it is not the state that handles the event but the machine. I was just trying for an abridged title for the model - not a formal definition. That said I talk about FSMs in a lot of ways, often to people who have never read a CS text in their lives. Some of the things that they might have read include ITU Z.100 (SDL) which maps rather nicely to Andrey's DSL (except for the lack of a way to send an event back to the machine from within the event handler, something that Andrey cosnders out of scope for the library).
typedef mpl::vector< fsm::transition<Attached, fsm::event<PowerOn>, Powered>, SetAddressTrans<Default, std::not_equal_to, Address>, SetAddressTrans<Address, std::equal_to, Default>, SetConfigurationTrans<Address, std::not_equal_to, Configured>, SetConfigurationTrans<Configured, std::equal_to, Address>, fsm::transition<fsm::any_state, fsm::event<Reset>, Default>, fsm::transition<fsm::any_state, fsm::event<PowerOff>, Attached>
::type Transitions;
The bits enclosed by fsm::transition look like they might be rows in an STT, although they're awfully verbose, with a great deal of surrounding syntactic noise that distracts from being able to read the actual semantics. AFAICT, the other parts do not bear any obvious resemblance to rows in an STT.
I agree that the convenience classes that Andrey put together to encapsulate the data dependend (gated) transitions are irregular. Can you suggest a better approach to deal with them?