David Abrahams wrote:
on Sun Aug 17 2008, Darryl Green <darryl.green-AT-aanet.com.au> wrote:
in this trivial FSM where much of the state is directly encoded in a couple of variables,
I don't know what the number of variables has to do with anything. For all practical purposes, unless you allow nested states or other esoteric extensions to the traditional CS meaning of FSM, 16 bits is more than enough to encode the state of arbitrarily complex state machines.
I'm sorry, I don't follow you. The question was not about how to encode the state but about whether FSM concept is needed here. No matter, though.
but you do seem to find the proposed libraries representation less useful. Is it simply that the "states that handle events" model is intrinsically not as clear as a diagram or transition table,
I think so. To start with, "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.
So, you're saying that the library must be designed as Wikipedia says? No less, no more? How discouraging.
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.
The library supports both approaches for defining the FSM - the state-based and the transition-based. I for one prefer state-based approach and you, I assume, prefer transition-based. To my mind, it is advantage that the library can be used both ways.
or is there some unnecessary verbosity or lack of clarity in way that model is expressed in the language implemented by the library?
Well, that too.
Where's yours?
I've pasted it here:
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.
Sorry, I don't see why the code above is worse than this: struct transition_table : mpl::vector11< row < Stopped , play , Playing , &p::start_playback >, row < Stopped , open_close , Open , &p::open_drawer >, row < Open , open_close , Empty , &p::close_drawer >, row < Empty , open_close , Open , &p::open_drawer >, row < Empty , cd_detected , Stopped , &p::store_cd_info >, row < Playing , stop , Stopped , &p::stop_playback >, row < Playing , pause , Paused , &p::pause_playback >, row < Playing , open_close , Open , &p::stop_and_open >, row < Paused , play , Playing , &p::resume_playback >, row < Paused , stop , Stopped , &p::stop_playback >, row < Paused , open_close , Open , &p::stop_and_open >
{};
In fact, I find your syntax more verbose for the unneeded fourth column of the table.