Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-18 13:05:23


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk