Actors and message-passing a la Erlang

Hello ! I've been studying Erlang and Scala, and I was wondering if someone has already implemented an actors and message passing framework for concurrent and distributed programs in Haskell.

Volker Stolz and Frank Huch implemented Erlang style distribution/concurrency for Haskell quite a while ago - a search should turn up the relevant papers, the code might have disappeared.

On 26 July 2010 06:55, Yves Parès
I've been studying Erlang and Scala, and I was wondering if someone has already implemented an actors and message passing framework for concurrent and distributed programs in Haskell.
I've recently been working on MPI bindings for Haskell: http://github.com/bjpop/bindings-mpi They are incomplete, but usable. Cheers, Bernie.

On 25/07/10 21:55, Yves Parès wrote:
Hello !
I've been studying Erlang and Scala, and I was wondering if someone has already implemented an actors and message passing framework for concurrent and distributed programs in Haskell.
Hi, Take a look at the concurrency section on Hackage: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:concurrency The actor library and eprocess library mention Erlang, but it seems like no other libraries attempting to replicate Erlang's concurrency model have made it on to Hackage. I wonder if part of the reason for this is that Erlang uses untyped (or should that be dynamically typed?) communication, which doesn't set as easily with Haskell's static typing. (Looking at the Haskell concurrency libraries on that list suggests that Haskell concurrency tends to focus either on transactions or on typed channels as a concurrency mechanism instead.) Thanks, Neil.

By the way, it is easy to implement "selective receive" using
first-class-patterns (this is the package's name, IIRC).
2010/7/26 Neil Brown
On 25/07/10 21:55, Yves Parčs wrote:
Hello !
I've been studying Erlang and Scala, and I was wondering if someone has already implemented an actors and message passing framework for concurrent and distributed programs in Haskell.
Hi,
Take a look at the concurrency section on Hackage: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:concurrency
The actor library and eprocess library mention Erlang, but it seems like no other libraries attempting to replicate Erlang's concurrency model have made it on to Hackage. I wonder if part of the reason for this is that Erlang uses untyped (or should that be dynamically typed?) communication, which doesn't set as easily with Haskell's static typing. (Looking at the Haskell concurrency libraries on that list suggests that Haskell concurrency tends to focus either on transactions or on typed channels as a concurrency mechanism instead.)
Thanks,
Neil.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Eugene Kirpichov Senior Software Engineer, Grid Dynamics http://www.griddynamics.com/

Hi, I don't know if this solves your problem, but maybe you should take a look at the Holumbus-Distribution package: http://hackage.haskell.org/package/Holumbus-Distribution I've build this library because I needed a simple way to transfer messages between two haskell processes or threads.The current code can be found under Holumbus.Distribution.* especially the DNode and the DStreamPort modules. The modules located under Holumbus.Network are deprecated. Best Regards, Stefan

In fact, I noticed Holumbus.
You say that "With the help of this library it is possible to build
Erlang-Style mailboxes", but how would you solve the issue of static typing?
Besides, Holumbus depends on package 'unix', preventing it from being used
on non-unix platforms.
2010/7/26 Stefan Schmidt
Hi,
I don't know if this solves your problem, but maybe you should take a look at the Holumbus-Distribution package:
http://hackage.haskell.org/package/Holumbus-Distribution
I've build this library because I needed a simple way to transfer messages between two haskell processes or threads.The current code can be found under
Holumbus.Distribution.*
especially the DNode and the DStreamPort modules.
The modules located under Holumbus.Network are deprecated.
Best Regards,
Stefan

Hi Yves,
You say that "With the help of this library it is possible to build Erlang-Style mailboxes", but how would you solve the issue of static typing?
this wasn't an issue for me because I wanted as much type checking as possible. In many implementations, you have an implicit contract between the sender and the receiver process. In this case, the contract is explicit and the compiler can tell me if I'm trying to send or receive "wrong" data.
Besides, Holumbus depends on package 'unix', preventing it from being used on non-unix platforms.
Oh... hmm, I think, the unix-package is only needed for the console-modules. The distribution modules should not need them, but I may be wrong. I don't have access to proprietary plattforms, but I think about splitting the distribution package and extract the communication modules. Stefan

On Tue, Jul 27, 2010 at 5:27 AM, Stefan Schmidt < stefanschmidt42@googlemail.com> wrote:
Hi Yves,
You say that "With the help of this library it is possible to build Erlang-Style mailboxes", but how would you solve the issue of static typing?
this wasn't an issue for me because I wanted as much type checking as possible. In many implementations, you have an implicit contract between the sender and the receiver process. In this case, the contract is explicit and the compiler can tell me if I'm trying to send or receive "wrong" data.
I've found that I like Erlang's pattern matching for sorting through different kinds of data payloads, but that I prefer to use typed data channels per Limbo, Go, Plan 9's thread and messaging libraries etc. I've often wanted an Erlang with static typing to get this capability.

This may not be of direct interest to the Haskell community but I thought
I'd share this information anyway.
If you are looking for a solution (in Erlang that runs on Erlang's virtual
machine) to enforce an explicit contract between a client and a server,
there is framework called UBF. This framework is designed for providing
rpc-like services based on a contract. The contract is enforced
dynamically at runtime (not at compile time).
The original implementation was made by Joe Armstrong
(http://www.sics.se/~joe/ubf/site/home.html). An updated implementation
with new features is currently hosted on GitHub (www.github.com/norton).
thanks,
- Joe N.
On Tue, 27 Jul 2010 22:13:07 +0900, David Leimbach
On Tue, Jul 27, 2010 at 5:27 AM, Stefan Schmidt < stefanschmidt42@googlemail.com> wrote:
Hi Yves,
You say that "With the help of this library it is possible to build Erlang-Style mailboxes", but how would you solve the issue of static typing?
this wasn't an issue for me because I wanted as much type checking as possible. In many implementations, you have an implicit contract between the sender and the receiver process. In this case, the contract is explicit and the compiler can tell me if I'm trying to send or receive "wrong" data.
I've found that I like Erlang's pattern matching for sorting through different kinds of data payloads, but that I prefer to use typed data channels per Limbo, Go, Plan 9's thread and messaging libraries etc. I've often wanted an Erlang with static typing to get this capability.
-- norton@alum.mit.edu

I've found that I like Erlang's pattern matching for sorting through different kinds of data payloads, but that I prefer to use typed data channels per Limbo, Go, Plan 9's thread and messaging libraries etc. I've often wanted an Erlang with static typing to get this capability.
Actually you are right. And it is not much of a chore to write:
data MyMessages = Something XXX | SomethingElse YYY ZZZ | Stop | ...
given that it ensures your message-passing is correct at compile time.
It gives you an Actor type like:
data Actor msgIn msgOut
Where msgIn is the type of received messages (Erlang's 'receive') and msgOut
the type of sent messages (Erlang's '!').
2010/7/27 David Leimbach
On Tue, Jul 27, 2010 at 5:27 AM, Stefan Schmidt < stefanschmidt42@googlemail.com> wrote:
Hi Yves,
You say that "With the help of this library it is possible to build Erlang-Style mailboxes", but how would you solve the issue of static typing?
this wasn't an issue for me because I wanted as much type checking as possible. In many implementations, you have an implicit contract between the sender and the receiver process. In this case, the contract is explicit and the compiler can tell me if I'm trying to send or receive "wrong" data.
I've found that I like Erlang's pattern matching for sorting through different kinds of data payloads, but that I prefer to use typed data channels per Limbo, Go, Plan 9's thread and messaging libraries etc. I've often wanted an Erlang with static typing to get this capability.

I think most of the Erlang style actors with message passing can be done in
Haskell with just TChan and forkIO.
http://en.wikibooks.org/wiki/Haskell/Concurrency
- Job
On Sun, Jul 25, 2010 at 4:55 PM, Yves Parès
Hello !
I've been studying Erlang and Scala, and I was wondering if someone has already implemented an actors and message passing framework for concurrent and distributed programs in Haskell.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Not distributed (yet) but concurrent:
http://hackage.haskell.org/package/actor
The paper " Actors with Multi-headed Message Receive Patterns. COORDINATION
2008http://www.informatik.uni-trier.de/%7Eley/db/conf/coordination/coordination2...:"
describes the design rationale.
Cheers,
Martin
On Sun, Jul 25, 2010 at 10:55 PM, Yves Parès
Hello !
I've been studying Erlang and Scala, and I was wondering if someone has already implemented an actors and message passing framework for concurrent and distributed programs in Haskell.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (10)
-
Bernie Pope
-
David Leimbach
-
Eugene Kirpichov
-
Job Vranish
-
Joseph Wayne Norton
-
Martin Sulzmann
-
Neil Brown
-
Stefan Schmidt
-
Stephen Tetley
-
Yves Parès