plain_fsm - for beginners and purists

[Shawn Pearce]

Ulf Wiger <ulf.wiger@REDACTED> wrote:
> One interesting twist of the above is that it will actually
> _appear_ to work, even if you forget to do the parse_transform -
> it just doesn't handle system messages like you thought it
> would. The wrapper function used in plain_fsm will actually
> exit if you ever call it directly. So if you forget to do
> the parse_transform, your program will exit immediately
> with a reasonably descriptive exit reason.

Yea, I noticed that.  Nice touch.  The more that I think about what
you've said during this thread, the more I realize you may very well
have gone with the overall best approach.  The syntax is horrible with
regards to what it actually means, but it may yeild the least surprises
in every regard.

It would be nice if the code just didn't compile if you forgot the parse
transform, rather than waiting until runtime to crash however. :)

> Actually, very few code changes break funs nowadays.
> I thought using a fun was the (conceptually) cleanest way
> of passing the continuation, but plain_fsm also supports
> passing the name of the function (which then has to be
> exported.)

I thought a fun wasn't usable after a module was reloaded, because the
reference to the code that the fun was using was directly to the
a single version of the module (and not an external call)?

Besides, can't a fun's magic name change between compiles, especially
if I add another fun, so if it did use an external call to execute the
fun in the new module, it might run the wrong fun?

> or, since we're transforming tokens anyway, why not invent something
> entirely different -- a user-provided keyword syntax:
> 
>    idle(S) ->
>       |plain_fsm::receive|
>            ...
>       end.

This is interesting.  New keywords will mess with nearly any indent
code that actually reads and relies on the keywords.  :)  But with the
above, you could actually have an indent program understand what was
meant:

	| (start user kewyord)
	plain_fsm (name of module that will supply the parse transform)
	:: (split between module and original keyword)
	receive (native erlang keyword most like this new keyword)
	| (end user keyword)

If this is the road taken, I'd like to ask that we make sure its
stackable:

	plain_fsm_receive my_app_receive
	....
	end.

Or:

	-keyword(plain_fsm_receive, my_app_receive).

	plain_fsm_receive
	...
	end.

with the parse transform converting to my_app_receive, (rather than
just receive) so another parse transform can kick in.  This is already
possible with your current design, so perhaps that's really the best
we have today...

-- 
Shawn.