Re: [boost] Is there any interest in a library for actor programming?

On Sun, May 19, 2013 at 5:48 PM, Dominik Charousset < dominik.charousset@haw-hamburg.de> wrote:

On May 18, 2013, at 11:54 PM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> wrote:

...

Le 17/05/13 23:26, Charousset, Dominik a écrit :

...

Hi,

is there any interest in a library for actor programming?

The library we've developed is a C++11 open source library named "libcppa".

...

There is something that I would like to see on the Actors architecture. The interface of an actor is not really defined other than by their behavior. It can receive any dynamic tuple. This is a lot. I would like a more statically typed interface. An actor could define statically the kind of messages/signals it is allowed to handle and make it part of the interface.

There was some discussion about this topic after the talk at the C++Now conference.

To continue that discussion...

I do agree that it is desirable to enable the compiler to verify the correctness of actor programs at compile time. However, in order to be able to ensure the correctness of a program, one would have to define not only all possible input messages, but the response types depending on the input as well.

Yes, and when writing code with strong compiler guarantees, this is a desirable feature.

However, an approach like this cannot allow an actor to change its behavior.

I think there is a large subset of use-cases where there is a willingness to disallow an actor to "change its behavior" (aka, change its type), in order to gain the benefit of compile-time guarantees.

Hence, something as simple as the classical dining philosophers example ( https://github.com/Neverlord/libcppa/blob/master/examples/message_passing/di...) is not possible.

I don't think it's been demonstrated that the 'typed' and 'untyped' approaches are mutually exclusive. For a Boost.Actor library, I would really like to see static types being well supported. That would likely be the only type of Actor library I would personally use in practice. Strong compiler guarantees enable safe refactoring of large applications, which is where C++ shines. I wouldn't object to there being a trap door to type-unsafety to fit some need, though its use should rightfully be discouraged. Long story short: a type-safe interface would be less powerful and would

require more boilerplate code.

The same argument can be used for any dynamic vs. static type argument. The user base of this library has already taken a stance on the issue by their choice of C++. That may be why there is so much push back to the current dynamic approach of libcppa.

However, perhaps there is a middle ground for doing type checks at runtime when compiled in debug mode?

int my_actor() { // macro, defined as nothing if not compiled in debug mode assert_protocol(reacts_to::with<int>, reacts_to::withstd::string); }

This mimics the python approach to check types at runtime. The whole benefit of compile time safety is that we get guarantees about code correctness *before* we run. -- David Sankel