large gen_fsms

[Alex Arnon]

On 3/20/06, Richard Cameron <camster@REDACTED> wrote:
>
>
> On 20 Mar 2006, at 13:43, Serge Aleynikov wrote:
>
> > I wonder if someone could share their experience at dealing with
> > large FSMs.  We are in the midst of implementing an FSM which
> > logically can be broken down in two groups of states.  It would be
> > good to be able to split these states among two separate modules,
> > but gen_fsm doesn't allow to do this easily.
>
> I always seem end up writing large FSMs as special processes (<http://
> erlang.se/doc/doc-5.4.12/doc/design_principles/spec_proc.html>) and
> simply doing things the old fashioned pure Erlang way:
>
> state1() ->
>         receive
>                 go_to_state_2 -> state2();
>                 _ -> state1()
>         end.
>
> state2() ->
>         receive
>                 go_to_state_1 -> state1();
>                 go_to_state_3 -> state2()
>         end.
>
> ...
>
> Something like that would let you split the states over multiple
> modules (assuming you can keep a mental image of the maze of cross-
> module calls in your head).
>
> The problem always find I have with gen_fsm is that events need to be
> dealt with immediately. You've got the option to either pattern match
> with a "don't care" variable to simply ignore an event if it occurs
> when you don't want it, or you can have the FSM abnormally. What you
> can't do is queue the event up to be dealt with when the FSM moves
> into a more appropriate state.
>
> I generally find that I want precisely this behaviour in at least one
> of my states (and this becomes more likely the bigger the FSM is). As
> Erlang's syntax is almost ideal of writing FSMs anyway, I just don't
> find gen_fsm adding much (other than taking care of OTP system
> messages automatically.).
>
> Richard.
>

Wouldn't this cause the stack to bloat indefinitely? Or does tail-calling
eliminate this in Erlang?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060320/0879712e/attachment.htm>