A second installment of my attempt to code erlang-style concurrency abstraction in haskell. The effort in part I, was a bit short of the mark. Here I try to address some of the shortcomings, while leaving others open.

The main problem was that the receiver could escape outside of the process, which can cause various hard to debug mayhem. What will happen if two different threads receive data from the same channel? Yes, it might be intentional, but you could always duplicate a channel for that. What if it is a bug? What if it is a piece of malicious code? Better safe than sorry.

I'm on a learning haskell journey. But reading someone else's code and thoughts while educational is not that enlightening. Anyway, to cut the long story short:

• I (still) want to see what this haskell thing is all about
• I need a moderately complex problem to get a feeling of the haskell type system works, face the dreaded IO, while not wasting too much time
• I need a decent actor style abstraction for some social/population based methods experiments I'm into

So this is how ended with Why not try my hand at erlang style concurrency. The best thing about it is that it aligns nicely with an individualistic view of the world. I can write sequential code to do something, which from time to time communicates with the rest of them, while the rest of the time doesn't really care.

Erlang implements lightweight processes with asynchronous messaging. The cool twist it puts on it is having reception guards - if a message is not matched by the guard conditions it stays in the mailbox (channel), and the rest of the messages are scanned. The first matching message is removed from the mailbox, the remaining messages are left in the mailbox in arrival order.