Agents vs. Actors

[Nils Bertschinger]

Hi,

how do Clojure agents relate to Erlang actors?
To gain some insights, I tried to implement Erlang style message
passing between agents. The first version is just a very incomplete
sketch (no mailbox, case instead of pattern matching ...), but already
shows that it is quite easily doable:
https://github.com/bertschi/clojure-stuff/blob/master/src/stuff/actors.clj

The idea is that the agent holds a dispatch function which is then
called by ! (send) with the message to be send. Somehow it resembles
the way closures can be used to implement an object system. Thus,
agents seem to be the functional analog of agents:
Functional programming Object-oriented
programming
sequential closure
object
concurrent agent
actors

Another great design from Rich Hickey! Clojure is fun and gets better
every day ...

Thanks,

Nils

[Stuart Sierra]

> how do Clojure agents relate to Erlang actors?

There are several important differences:

1. Agents are designed for in-process communication only.

2. Observing the state of an Agent does not require sending it a message.

3. Agents accept arbitrary functions instead of a predefined set of messages.

-S

[Nils Bertschinger]

Hi Stuart,

thanks for the info. I did not really think about some of these
differences. Basically, it was just a fun exercise ... not (yet)
useful for anything serious.

On Dec 2, 10:14 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:
> > how do Clojure agents relate to Erlang actors?
>
> There are several important differences:
>
> 1. Agents are designed for in-process communication only.

Right, whereas Erlang actors are distributed. This was not so
important for me at the moment.

>
> 2. Observing the state of an Agent does not require sending it a message.

Good point, I must have forgotten that ... maybe this makes agents
actually more general than actors?

>
> 3. Agents accept arbitrary functions instead of a predefined set of
> messages.

That is true, but I was wondering whether it is possible to simulate
Erlang style messages with this. In my sketch the state of an agent is
a handler function which only accepts a limited set of messages. Seems
to be a close fake of Erlang actors (and reading the state without
sending a message as in 2. is not very useful since it only returns
the handler function ... calling this function then acts as a send).
>
> -S

Best,

Nils

[Benny Tsai]

Hi Nils,

A while back, I also took a stab* at implementing Erlang-style actors in Clojure, along with solutions for a few classic concurrency problems (Dining Philosophers, Sleeping Barber).  I was blown away by how easy it was to implement actor semantics on top of agents.

Comparing our respective efforts, I see a lot of room for improvement in mine :)  I like how your actors send messages containing the address of the recipient, which seems truer to the actor model.  Also, you raise a great point regarding pattern matching; I think that can greatly simplify the message handlers in my code.  Looks like it's time for me to get acquainted with core.match :)

Thanks for the food for thought!

*https://github.com/bitsai/clojure-actors

[Nils Bertschinger]

Hi Benny,

On Dec 3, 9:21 pm, Benny Tsai <benny.t...@gmail.com> wrote:
> Hi Nils,
>
> A while back, I also took a stab* at implementing Erlang-style actors in
> Clojure, along with solutions for a few classic concurrency problems
> (Dining Philosophers, Sleeping Barber).  I was blown away by how easy it
> was to implement actor semantics on top of agents.

looks good. Somewhat different approach where the state of the agent
is handled more explicitly. I tried to stay close to Erlang, so the
state is wrapped in a closire which acts as my matching function.
It might also be interesting to solve some of those classic
concurrency problems the Clojure way and compare to the actor
solutions.

>
> Comparing our respective efforts, I see a lot of room for improvement in
> mine :)  I like how your actors send messages containing the address of the
> recipient, which seems truer to the actor model.  Also, you raise a great

Actually, I do not include the address of the recipient into the
message. The message is simply a symbol and then dispatched in a case
statement.
The example might be slightly confusing since the actors are
named :ping and :pong and send messages "ping" and "pong" to each
other.
It's really a very simple sketch ... no pattern matching on messages
and no mailboxes.

> point regarding pattern matching; I think that can greatly simplify the
> message handlers in my code.  Looks like it's time for me to get acquainted
> with core.match :)

This seems to be the right approach to fake Erlang-style message
handlers.