plain_fsm - for beginners and purists

[Vlad Dumitrescu]

Hi Ulf and Shawn,

Are you going to start the revolution without me!? :-D

***

I like the plain_fsm idea. However, I'm not very happy with either the parse
transform or the other solutions. My first instinct was to use a macro, as Shawn
suggested, but got a more than good explanation of why it doesn't work.

There is one more alternative that wasn't discussed yet:

receive
    .... %% nomal caluses
    Msg ->
        plain_fsm:handle(State, Msg)
end;

This is all plain Erlang, and nobody can misunderstand it. One possible problem
is that we can't have this handling before all other processing, but it doesn't
feels like a big constraint. Are there other reasons, Ulf? ;-)

***

About the advances in scanning and parsing technology, I'd like to argue that
they effectively create a new language. This is not wrong per se, but I'm not
sure if it should be called Erlang then.

The idea is very appealing, and I suppose there are already such languages being
researched. If such degree of freedom is wanted, why not go to the roots and use
Lisp? One can build almost any syntax on top of it, and for semantic changes the
macros are already there. ;-)

***

Since you also mentioned the !! operator, I have some problems with it (as it is
defined now). While the idea is good, I feel that if it's going to be part of
the language, the behaviour should not be user-defined. If one will be able to
define an own rpc function to be used by !!, it's not going to be clear what the
code does without knowledge of it.

Another problem is that I feel that I'd like to be able to set a timeout for a
rpc call. In this respect, an operator is less flexible than the corresponding
function call.

***
Just my 2 cents.

best regards,
Vlad