Big state machines

Ulf Wiger ulf@REDACTED
Sat Apr 23 08:50:47 CEST 2005

Den 2005-04-23 00:16:52 skrev Vance Shipley <vances@REDACTED>:

> On Fri, Apr 22, 2005 at 10:09:49PM +0200, Ulf Wiger wrote:
> }
> }  I think this is somewhat analogous to having a gen_fsm that
> }  performs a gen_server:call() in one of its callbacks.
> But is that desired functionality?  I'm thinking not.
> On the other hand with my method you can have it that
> way if you wish.

Also with plain_fsm, with the limitation that it
required the function to have only one argument: the state.
Perhaps this had more to do with my inability to write
a sufficiently flexible parse_transform... (:

> }  It's probably a good idea to always have the ?SYSTEM
> }  and ?EXIT macros present, and writing it symmetrically
> }  like you've done. Then, of course, one could discuss
> }  whether they need to be two separate macros, but
> }  OTOH that might serve to clarify what's happening.
> My thinking was that instead of hiding the system messages I
> wanted the coder to think about how these messages should be
> handled.  It might be that you wanted to defer EXIT processing
> briefly for instance but still handle system messages.

Being explicit certainly has its advantages. I think the
main benefit of plain_fsm might be that it can also serve
as a library for people who want to handle system messages
explicitly - much like your sysFsm. Was there anything
missing in the plain_fsm utility functions that made you
write your own library? Or was it perhaps because I hadn't
documented the option of skipping the parse transform and
writing more or less the way you did?

BTW, I have a version of plain_fsm that also does some
really bizarre stuff with erlang:hibernate/3. Basically,
it bootstraps itself to new code using a code_change
function as soon as the next message comes in.
It's been lying around since I ran into problems with
the parse transform. But if you want to do without the
transform, it should be perfectly useable as it is.

I could send it to you if you want to play with it.


More information about the erlang-questions mailing list