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

[Matthew Dempsky]

On Tue, Apr 15, 2008 at 9:26 AM, Roberto Saccon <rsaccon@REDACTED> wrote:
>  First, I would like to know if there is any formal description of
>  Mnesia's commit protocols. Any paper, page, manual?

I don't know of any.

>  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?

That paper's the only reference I know of other than the source
(compiler/src/sys_expand_pmod.erl handles rewriting abstract forms
from a parameterized module).

>  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.

Erlang's standard distribution protocol uses TCP, which can't run over
IP multicast.  There's an API for writing your own distribution
modules, but it's non-trivial and I don't know off hand if the API
would allow for multicast anyways.

>  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).

Depending on the situation, you could write a macro for ?condx or
something.  Otherwise you'd probably have to pull out all of the M
messages and maintain your own mailbox.

>  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.

I don't know of anything other than manually relaying messages.