plain_fsm - for beginners and purists

Shawn Pearce spearce@REDACTED
Wed Feb 11 06:11:10 CET 2004

Ulf, I read through your plain_fsm today and found it pretty
interesting.  Last night I put together a simpler version of gen_fsm
which provides some better support for my specific domain than the
standard gen_fsm, but it is still the same async mess you were objecting
to with the development of plain_fsm.

I have to say, I think plain_fsm is a nice advance over gen_fsm, and
would love to see some form of it in OTP proper.  I only have two

The parse transform wrapper doesn't make sense when you intially read
it.  In fact, it looks like it couldn't possibly do what it is actually
doing, as it seems like a non tail-recursive function being setup,
which is horrible in a persistant server (yes, I know its actually
making correct code, I'm saying that reading it initially has you
reading it wrong):

	idle(S) ->
			do_nothing -> idle(S)

I'd suggest a different parse transform, or just a plain macro:

	idle(S) ->
		do_nothing -> idle(S)

	idle(S) ->
		do_nothing -> idle(S)

In the first case, the parse transform just looks for the special atom,
removes the clause, and inserts the two special ones for system and
parent support.  In the second case, the macro just expands to the two

I find the second the lazyman's way out, while the first with the parse
transform is much more elegant, and keeps to basic Erlang syntax. It
also lets you order the system/parent exit events with regards to the
other events in the receive statement.

My other comment has to do with exit failure.  If a plain_fsm crashes
its parent will receive the {'EXIT', P, R} message (or crash itself).
But who writes out the error_report through error_logger?  I find this
very valuable that every gen_server and gen_fsm process will write
its crash report to the error log, without the developer needing to
ensure this happens.

To that end, I'd propose starting a master server on each node when
the first plain_fsm is started, and have that master server monitor
each plain_fsm.  This way the error report can be logged out by a
stable code base which will ensure the errors are always written...

I should have looked at plain_fsm sooner, as I might have just used it
as my foundation instead of gen_fsm...  :-(

On a side note, a different (little) behavior I just put together is
355 lines of code.  Most of this code seems to be largely related to
the requirements of being a good citizen (using sys, handling system
messages, code changes, etc) and good error trapping and reporting
(prior to letting the process fully crash out).

Has anyone found a shorter way to write behavio(u)rs?  Granted its a
lot of functionality packed into a small space (my implementations are
just 20-50 lines), but it seems like quite a bit of code to me...

Ulf Wiger <ulf.wiger@REDACTED> wrote:
> On Sat, 07 Feb 2004 01:30:37 +0100, Ulf Wiger <ulf.wiger@REDACTED> 
> wrote:
> >
> >I have checked in a behaviour/library in the Jungerl(*) called plain_fsm.
> >The idea is that you should be able to write "classic" erlang state 
> >machines without having to give up support for OTP system messages
> >(suspend, resume, get_status, code_change).
> >
> >(*) for those who have happened to miss 
> >it.
> >
> >I would very much like some input.
> (replying to my own post...)
> I have, in an attempt to make it more accessible, put the plain_fsm
> archive, browsable code and documentation on
> The direct link to the plain_fsm documentation is:
> Someone with a lot of spare time should do something nice with
> Richard Carlsson's new edoc, somehow publishing the documentation
> of the different Jungerl apps in a web-browsable format on
> SourceForge (ViewCVS doesn't seem to be able to handle HTML well.)
> /Uffe
> -- 
> Ulf Wiger


  It's gonna be alright,
  It's almost midnight,
  And I've got two more bottles of wine.

More information about the erlang-questions mailing list