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

On 08.06.2013, at 20:11, David Sankel wrote:

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.

Oh, I don't think they are. The problem with C++ is the limited meta programming capability. Unfortunately, we cannot traverse the AST. We are only allowed to introspect types and function signatures using template meta programming. Hence, wen cannot look "inside" of an actor implementation to extract all the type information we need by parsing become() and reply() statements. Clang offers a plugin infrastructure to give developers the opportunity to read and manipulate the AST directly, but there is no standard compliant way to do so.

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.

I think providing a strongly typed subset of the library along with the "fully dynamic" version should be a good middle ground. Type safe actors will be more or less lifted functions, where we can derive all the type information we need from the signature.

...

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.

It depends on what you want to achieve. In a largely distributed system, you want to be able to pass addresses around, read addresses from configuration (text) files, etc. You can do this with actors just as you can do it with web (HTTP) addresses. You have a communication layer that only needs addresses and transmits (any) messages. The protocol is a trait between sender/client and receiver/server. However, if you are designing a tightly coupled system, you're only interested in the message passing (and maybe the failure model) part of the actor model. I guess this is your domain. In such a scenario, you are in control of all components and you want the protocol between the components to be checked before you deploy and run your application, i.e., at compile time. Best regards, Dominik