Evaluating Expressions, part 6 – Actor Primitives

[Dale Schumacher]

Implementing language features using Actors has reached the point
where the actor primitives themselves can be described
meta-circularly.

http://bit.ly/9KfHLI

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[Owen Densmore]

The Actor pattern certainly seems to map on to Agents in modeling.

I'm fascinated by the lack of globals.  I wonder how that is handled?  Is there a Factory that can hold the global information needed by Actors?

If all this can have reasonable performance, especially in a distributed system, it'd be a good model for some of the distributed ABM ideas we've been considering.

Oddly enough, we've thought of Javascript as a good language to use.  Its everywhere, becoming so pervasive on the server side that one company, Joyent, is converting to it for its hosting services.  That would lead us to use it on the client, the server, and via JSON, as the messaging between client/server.  Indeed, we might go to a symmetric model where the client/server become the same, both being servers (async listening) and responding (sending messages).

One issue is the identity of the Actors involved.  We'd need something like a universal id for each so that they could find each other world wide.  Possibly a URL?

    -- Owen


On Nov 20, 2010, at 6:30 AM, Dale Schumacher wrote:

> Implementing language features using Actors has reached the point
> where the actor primitives themselves can be described
> meta-circularly.
>
> http://bit.ly/9KfHLI
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[Dale Schumacher]

On Sat, Nov 20, 2010 at 10:19 AM, Owen Densmore <[hidden email]> wrote:
> The Actor pattern certainly seems to map on to Agents in modeling.

There's certainly a lot of similarity between Actors and Agents,
especially at the conceptual level.  My understanding of Agents (and
I'm sure there are many on this list with a better understanding than
I) is that they are part of a simulation and thus have a critical
emphasis on modeling time.  Often discrete "generations" or "ticks"
are used as the time model, batching up a group of related
computations which define the value of the next discrete state of the
system as a function of the current state.  A colleague and I are
working on a genetic-algorithm solution to the traveling salesman
problem, modeled with actors, which is specifically designed to use a
continuous, rather than generational, model of time.

Actors are built on a causal-chain model of time.  Events can "cause"
other events to occur and state changes are "caused" by the occurrence
of an event.  Since all messages are asynchronous, and there is an
arbitrary delay between sending a message and it being received, the
only restriction on message ordering is that a message must be sent
before it can be received.  Actors representing "clocks" can be
introduced into the system and produce periodic events from which
other computations can be triggered.  If these events are driven from
an external source, such as periodic timer interrupts, then the rate
at which they occur can correspond to "real" time.

> I'm fascinated by the lack of globals.  I wonder how that is handled?  Is there a Factory that can hold the global information needed by Actors?

"Globals" are a relative concept.  They are simply identifiers which
represent the context common to a "whole" system/configuration.
Configurations can be nested, where identifiers in an "outer" context
appear "global" to the "inner" context(s).  If a group of actors
required access to a common resource, such as the definition of a
console "println" actor, then an identifier for the common resource
would be bound in a scope which enclosed the definitions of all the
actors in the group.  Any state which changes over time is modeled
with an actor.  Identifiers are bound to pure immutable values.  An
actor's identity (which is required in order to send it a message) is
a value, and may be bound to identifiers and passed in messages (which
are also values).  So there is no direct access to shared mutable
state, only shared contexts which provide identifiers for immutable
values, but those values can identify actors whose behavior changes
over time.

> If all this can have reasonable performance, especially in a distributed system, it'd be a good model for some of the distributed ABM ideas we've been considering.

Modest PC hardware can support MILLIONS of concurrent actors in an
efficient implementation.  Erlang is a reasonably efficient
implementation which also supports network distribution of
actors/processes.

> Oddly enough, we've thought of Javascript as a good language to use.  Its everywhere, becoming so pervasive on the server side that one company, Joyent, is converting to it for its hosting services.  That would lead us to use it on the client, the server, and via JSON, as the messaging between client/server.  Indeed, we might go to a symmetric model where the client/server become the same, both being servers (async listening) and responding (sending messages).

At a much larger granularity, actor-based thinking can be mapped onto
hybrid client/server network nodes.  The "node.js" project is doing
very interesting things with JavaScript-based creation of asynchronous
servers.

> One issue is the identity of the Actors involved.  We'd need something like a universal id for each so that they could find each other world wide.  Possibly a URL?

Management and representation of actor identities is a key issue is
creating large-scale distributed systems.  URI schemes certainly seem
to have some applicability here.  However, note that not all actors
need to be "universally" addressable.  Some actors will only interact
with a small group of collaborators, often within a single address
space, and possibly only exist for a very short period of time.
Others may well represent long-lived "well known" services, and may be
implemented by whole configurations of smaller actors communicated
through a network end-point "facade".  Network addressable "proxies"
can also be dynamically created when/if an actor wants to provide
access to a "remote" peer.

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org