[deleted]
Umm... didn't I spend something like three paragraphs not just saying that, but showing some code fragments too?
Yes, sorry. Misread you. Ignore my comment.
As Erlang is Turing-complete, obviously you can code FSM in it. The question is, giving Erlang/OTP Soft-Realtime Telecom roots, why FSM primitives are so weak?
From a good FSM library I would expect following:
1. Specify human readable STT (State Transition Table)
2. For each event/state combination specify if it's valid or should be ignored, etc.
3. On entry / on exit for each state.
4. Masking/unmasking of events.
That's not too hard to fix; write your handle_event callback as something that observes the state, dispatches out to the "really_handle_event" function, observes the new state, and fires the desired callback, implemented however you want them to be. Ten reusable lines or so.
"Also, I'm not sure you can use gen_fsm sequentially by itself (i.e. without Erlang process)."
Not really much point, really. The gen_fsm itself is basically wrapping the state machine described there into a supervisor tree. If you don't want the supervisor tree, it is utterly trivial to write a state machine of your own in Erlang. It is one place where pattern matching excels. You want some sort of record indicating your state, then you can do things like:
and so on. A little more plumbing is necessary to manage returning the new state but that's the basic idea, which is just about the only other thing you "get" from gen_fsm "for free".