General (not specific to LV/AF) Actor Theory

[AristosQueue (NI)]

These two guys are language theorists. Let me tell you about language theorists (the real ones... I'm just a dabbler):

The lambda calculus is sufficient to express all computability. It has only three rules (I have used a $ instead of the Greek letter lambda):

t is a lambda expression if

   t = x where x is a variable

   or

   t = $x.M where x is a variable and M is a lambda expression

   or

   t = (M N) where M and N are lambda expressions

Computation is simply reduction of lambda expressions. And, yes, you can write computer programs, all programs, with no more syntax than that. For example, the numerals 0, 1, 2... etc are written

0 = $s.($z.z)

1 = $s.($z.s(z))

2 = $s.($z.s(s(z)))

3 = $s.($z.s(s(s(z))))

And for a language theorist, this is where you define a language. Once you have these fundamentals, then we can talk about adding higher level syntax (like actually using the numerals to represent the numbers), but all of it gets reduced to the fundamental parts.

That's lambda calculus. These guys are expressing something similar for actor theory. So, yes, you could likely express actors as "a" and a connection from two actors as "a -> b" or some other minimalist notation. These guys are talking about actors all the way down at the assembly level, not the fifth-order programming language actors expressed by the Actor Framework. Keep that in mind when watching the video.

[drjdpowell]

Daklu wrote:

Queues, as implemented in Labview, impose restrictions with a concrete implementation that simplifies certain programming tasks but do not (as near as I can tell) function as an adequate communication mechanism for the generalized actor model.  In Labview, a queue refnum is effectively equivalent to the identity of the concurrent processes that will receive the message.  That is specifically not true in the actor model Hewitt presents.

Actually, in my "actors", the "addresses" aren't exactly equivalent to identity of the concurrent process, because I have container objects I call "Observers" that are also addresses, and they can contain an arbitrary number of other addresses and can modify messages before they are sent.  So a sending process cannot be sure how many actors it is sending a message to, and there can be multiple "addresses" that lead the same actor.  Same Queue under-the-hood, of course, but the sending actor cannot know that. 

[drjdpowell]

Here is an interesting article on "actors" I found:

[Daklu]

Actually, in my "actors", the "addresses" aren't exactly equivalent to identity of the concurrent process, because I have container objects I call "Observers" that are also addresses, and they can contain an arbitrary number of other addresses and can modify messages before they are sent.  So a sending process cannot be sure how many actors it is sending a message to...

Right, and that illustrates my point.  We're implementing code constructs to allow us to write actor-based code, but in doing so we're forced to violate some of the properties of the actor model.  For example, is your Observer an actor?  If not then your implementation isn't faithful to the model because in the actor model there is nothing in the model that is not an actor.   If the Observer is an actor, then the sending actor does know how many actors it is sending a message to--one--and your implementation still isn't faithful to the model.  True, the sender does not know how many actors will eventually receive the message, but that isn't the question.

Incidentally, I call my constructs actors too, even though they are differences between your implementation and mine.  Mercer calls the AF constructs actors and they're different from both mine and yours.  Who is right?  Strictly speaking, none of us.  All of our implementations fall short of the model Hewitt described in one way or another.  That's fine with me.  It's not clear to me a programming language or framework that strictly implements the model would be as useful as one that makes calculated tradeoffs anyway. 

Does it matter if our implementations don't match the model exactly?  I honestly don't know.  The point of using the actor model is that it simplifies reasoning about concurrent programs.  I suspect as the implementation diverges from the model more opportunities for errors arise.

[drjdpowell]

Daklu wrote:

For example, is your Observer an actor?  If not then your implementation isn't faithful to the model because in the actor model there is nothing in the model that is not an actor. 

There must be some miscommunication or poor terminology going on.  Surely "an address" and "a message" are non-actor things in the model?   Anyway, why would "everything must be an actor" be an interesting or in any way useful prescription?  

Incidentally, I call my constructs actors too, even though they are differences between your implementation and mine.  Mercer calls the AF constructs actors and they're different from both mine and yours.  Who is right?  Strictly speaking, none of us.  All of our implementations fall short of the model Hewitt described in one way or another. 

I'm not convinced "everything is an actor", interpreted this way, is a meaningful part of the model.  Encapsulation of state information (no by-ref sharing of data) is the most important thing; I think we all do that.

[AristosQueue (NI)]

drjdpowell wrote:

I'm not convinced "everything is an actor", interpreted this way, is a meaningful part of the model.  Encapsulation of state information (no by-ref sharing of data) is the most important thing; I think we all do that.

It depends on your goal. If your goal is efficient implementation of functionality with a generally well-proven technique, it does not matter. If your goal is mathematic rigor in *proving* the efficiency and encapsulation of the code, I suspect it matters quite a lot. You can prove a whole lot of things about LISP, but introduce one global variable and a lot of those proofs no longer apply. That doesn't mean that you can't prove them true, but you have to go create new proofs rather than just scaling the old ones, and, in general, the new proofs are app-specific, not generalizable to all apps you write in the future. I'm willing to wager that something similar happens with the actor systems at scale.

Now, having said that, what I've built up for the Actor Framework is based on an alternate system that has certain constraints, and from those constraints, we can show* that the AF has certain properties when used as designed. Introduce any other parallel communications scheme and you're back to having to prove out correctness yourself.

* I use the term "show" not "prove" since I've never formalized a proof of correctness, something that lies outside my mathematical skill. I can present the reasoned argument for why the AF works, but I cannot prove that it holds in all cases. Thus far no one has been able to show a counterexample for things like concurrency correctness or scalability, but a proof would show that no such counterexample exists.

[drjdpowell]

But can you meaningfully define literally everything as an actor?  The numbers 0 and 1, like in your lambda calculus example?  The messages themselves?  The Cosine function? 

[lukepike]

I suppose only those things that have the 3 properties of actors (processing, storage, communication) can be considered actors. The cosine function has no storage or communication, it always does the same thing with the same input.

[AristosQueue (NI)]

drjdpowell wrote:

But can you meaningfully define literally everything as an actor?  The numbers 0 and 1, like in your lambda calculus example?  The messages themselves?  The Cosine function? 

I don't know, but it wouldn't surprise me if they've found a way to do the formalization. That's the thing about formal methods: they don't have to be practical. You can apply practical shortcuts on top of the implementation once the foundations are proven out.

Having said that, my suspicion is that this formalization applies solely to data storage and function invocation... some sort of pi calculus.

[AristosQueue (NI)]

lukepike wrote:

I suppose only those things that have the 3 properties of actors (processing, storage, communication) can be considered actors. The cosine function has no storage or communication, it always does the same thing with the same input.

So what you're saying is that its storage and communication are the null set. So it does have them... it just has "none" of them. It's not much of a formal system if it can't handle its own absence!  🙂