[erlang-questions] abstract/static modules, multicast, and best practices

[Roberto Saccon]

I just received a direct mail from someone, who tried  to post on the
Erlang  Mailing list, he tried everything ("I tryied posting directly
the list site on google groups and sending an email. I also mailed the
list owner, but never got a reply."),  but did not get through,so I am
posting this on behalf of: Lasaro Camargos <lasaro@REDACTED>:


===================================

Subject: abstract/static modules, multicast, and best practices.

Hi all,

I am newbie in erlang with some doubts that I couldn't clarify with
google's help. Hope you can help me with those.

First, I would like to know if there is any formal description of
Mnesia's commit protocols. Any paper, page, manual?

Second, recently I saw some discussion about abstract and static
modules in erlang. The only material that I found seems to be an
outdated academic paper (Parameterized modules in Erlang). Is there
where I can learn more about these abstract and static modules and
parameterized modules? Is the paper what has been implemented in
erlang?

Third, is there a way to use multicast in the erlang messaging system?
I know I could use IP Multicast, but I simply love the ! and receive
constructs.

Fourth, a more practical question. I use TLA+ to describe distributed
protocols and would like to stay as close as possible to it when
implementing these protocols.
TLA+ looks more or less like this,
Action def
  when CondA(State) and (CondB(State) or CondC(State))
  do state transition.

When I saw the guarded receives of erlang, it seemed like it would be
the perfect match since in my protocols, most actions are triggered by
a message receipt. I though would be able to write:
loop(State) ->
receive
 {M} when CondA(State) andalso CondB(State) ->
       StateN = doStateTransition1(State)
       loop(StateN)
 {M} when CondA(State) andalso CondC(State) ->
       StateN = doStateTransition2(State)
       loop(StateN)
end.

I saw from the many emails about guard expressions that you do not
plan to accept more complex functions as guards, so I won't even argue
that it would be awesome. Instead, I will just ask how would you
rewrite such a code knowing that the CondX functions not complex but
not too simple. Moreover, I would not like to take {M} out of the
queue unless it matches one of the receive clauses (messages that do
not match a clause may later match, if another message is processed
first).

Last, is there anyway of delegating the task of reception of a message
to another process? I will explain: I create a process to handle every
instance of my protocol. When an instance becomes too old and mostly
inactive, I would like to swap it off and delegate the task of the
receiving late messages to another process. This process would be
responsible for receiving messages for all the old instances and, in
rare case in which a message actually arrives, waking the instance
handler up. Can this be done? I would not like to have a proxy
receiving messages before any active instance process, though.

Best regards,
Lásaro

===================================


-- 
Roberto Saccon
http://rsaccon.com