<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


---

