Fri Jan 2 17:18:53 EST 2015

Static actors

So one would use actors to ensure robustness.  According to Joe
Armstrong, you need at least 2 machines to have robustness so
concurrency is an essential element.  Splitting tasks in supervisors
and "happy path" application code allows one to not handle errors
locally: just let it fail and let the supervisor restart = separation
of concerns.

Interesting, but a bit resource intensive.  I wonder if it's possble
to find subsets of this where the implementation is actually done by a
static set of state machines executing with static scheduling, and
statically known message queue sizes or getting rid of mailboxes
altogether (i.e. size = 1: just a variable to pass to another state

So what are the sets of constraints that need to be verified to make
actors reduce to static state machines with static or at least
predictable scheduling?

One particular element would be the need for a hidden "clock"
property, meaning that there is a concept of logical time that would
create equivalence between messages.

Essentially, for each kind of event, there is a DAG that computes
(input,state) -> (output, state).

I.e. the computation is finite.  For any kind of event, the response
of all actors is to block waiting for a new message.  All feedback
should either be through internal state, or externally to the system
(e.g. the real world).

I actually have code for this.  Maybe revive it?