<p>Erlang is an example. I actually don't know Erlang, so I'm going to use some pseudocode:</p>

<p>Suppose you have two threads, Alice and Bob. They talk by calling each other's <code>Send</code> member route, which blocks until the other end replies. Alice can keep some "mutable state" for a single integer as follows:</p>

<pre><code>Alice:
  function main_loop(state):
     message = Receive()
     if message == "get":
        Reply(state)
     else
        Reply("Okay")
        main_loop(message)
  main_loop(0)

Bob:
  Alice.Send(100) // Store 100 into the mutable state
  Alice.Send("get") // obtain the 100
  Alice.Send(200) // Store 200
  Alice.Send("get") // get the 200
</code></pre>

CC BY-SA 3.0
2014-12-13T20:53:18.060Z
2014-12-13T20:53:18.060Z
ithisa
<p>I just read <a href="http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html" rel="nofollow">this blog post</a> which argues that monads might be too obscure or difficult to understand as the default "interface to the impure world" in purely functional programming languages; instead, it suggests that the actor model would be more comprehensible when it comes to pedagogy.  That may be true -- I do think that actors are easier to understand than monads -- but the post leaves a lot to be desired.  In particular, the author offers no <em>examples</em> of what this sort of actor-based purely-functional language would look like, and he doesn't seem to have followed up on the blog post since it was written a few years ago.  </p>

<p>So my question is:  in what way can actors be leveraged to capture side-effects in a purely functional way?  How would source code in that hypothetical language look?  What advantages/disadvantages would that approach offer in comparison to monads (outside of the cosmetic differences)?  </p>

<functional-programming><concurrency><monad>
How can the actor model be applied to allow pure functional languages to have side-effects?
Ricky Stewart
# How can the actor model be applied to allow pure functional languages to have side-effects?

(Asked by: username_0 on 2014-06-26)

I just read [this blog post](http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html) which argues that monads might be too obscure or difficult to understand as the default "interface to the impure world" in purely functional programming languages; instead, it suggests that the actor model would be more comprehensible when it comes to pedagogy. That may be true -- I do think that actors are easier to understand than monads -- but the post leaves a lot to be desired. In particular, the author offers no *examples* of what this sort of actor-based purely-functional language would look like, and he doesn't seem to have followed up on the blog post since it was written a few years ago.

So my question is: in what way can actors be leveraged to capture side-effects in a purely functional way? How would source code in that hypothetical language look? What advantages/disadvantages would that approach offer in comparison to monads (outside of the cosmetic differences)?

**Tags:** functional-programming, concurrency, monad


---

## 1 answers

### Answer by username_1 on 2014-12-13. Score: 1

Erlang is an example. I actually don't know Erlang, so I'm going to use some pseudocode:

Suppose you have two threads, Alice and Bob. They talk by calling each other's `Send` member route, which blocks until the other end replies. Alice can keep some "mutable state" for a single integer as follows:

```
Alice:
  function main_loop(state):
     message = Receive()
     if message == "get":
        Reply(state)
     else
        Reply("Okay")
        main_loop(message)
  main_loop(0)

Bob:
  Alice.Send(100) // Store 100 into the mutable state
  Alice.Send("get") // obtain the 100
  Alice.Send(200) // Store 200
  Alice.Send("get") // get the 200

```


---

