An altogether different actor model

Hi Greg,

I'm intrigued by the contrast between your two statements about Actors
and Static Typing copied below. The second one reflects my evaluation of
Scala actors, so Im quite interested to see how you might better fit
them into static typing - that's surely in the future of Actors.

I suspect you might have tried to explain that in the latter part of
your letter, but I didn't understand it sufficiently. If you could give
a more concrete example in Scala-like syntax, that would be interesting.

My present feeling is that Scala actors would best evolve towards a
classic API, ie a set of named functions with typed parameters and
return values. Invoking on an Actor shouldn't look so different from
invoking on an Object, IMO. Jonas Boner blogged about some work in this
area in Scala OTP
[http://jonasboner.com/2008/12/11/real-world-scala-fault-tolerant-concurrent-asynchronous-components.html].
One difficulty is the way the a/synchronous divide gets papered over,
but I'm not convinced that's unsurmountable.What's your opinion on this
type of approach?

-Ben

Meredith Gregory wrote:
> Actors represent an interesting sweet spot because they
>
> ... - and turn out to fit into a static typing discipline
>
Meredith Gregory also wrote:
> Those familiar with Scala's
> "actors" have certainly experienced a similar step over the edge, in the
> sense that programming with Scala "actors" is not genuinely integrated with
> or supported by all the very sophisticated typing machinery of the
> functional kernel of the language

Hi,

Since you mentioned a 'classic' API for Scala actors, I thought I'd mention that I also did a bit of work about two and a half years ago on making actors more object oriented and typed. I tried to keep the same facilities as actors had with in Scala at that time, but from glancing at the link you posted it seems my work isn't as complete as the work by Jonas Boner, and I only ended up using it in a simple context. Anyway, in case people are interested:

http://www.ne-fat-s.org/objactor/index.html

Stefan

----------------------------------------
> Date: Tue, 18 Aug 2009 11:32:06 +1000
> From: benh [at] ibsglobalweb [dot] com
> To: lgreg [dot] meredith [at] gmail [dot] com
> CC: scala [at] listes [dot] epfl [dot] ch
> Subject: Re: [scala] An altogether different actor model
>
> Hi Greg,
>
> I'm intrigued by the contrast between your two statements about Actors
> and Static Typing copied below. The second one reflects my evaluation of
> Scala actors, so Im quite interested to see how you might better fit
> them into static typing - that's surely in the future of Actors.
>
> I suspect you might have tried to explain that in the latter part of
> your letter, but I didn't understand it sufficiently. If you could give
> a more concrete example in Scala-like syntax, that would be interesting.
>
> My present feeling is that Scala actors would best evolve towards a
> classic API, ie a set of named functions with typed parameters and
> return values. Invoking on an Actor shouldn't look so different from
> invoking on an Object, IMO. Jonas Boner blogged about some work in this
> area in Scala OTP
> [http://jonasboner.com/2008/12/11/real-world-scala-fault-tolerant-concurrent-asynchronous-components.html].
> One difficulty is the way the a/synchronous divide gets papered over,
> but I'm not convinced that's unsurmountable.What's your opinion on this
> type of approach?
>
> -Ben
>
> Meredith Gregory wrote:
>> Actors represent an interesting sweet spot because they
>>
>> ... - and turn out to fit into a static typing discipline
>>
> Meredith Gregory also wrote:
>> Those familiar with Scala's
>> "actors" have certainly experienced a similar step over the edge, in the
>> sense that programming with Scala "actors" is not genuinely integrated with
>> or supported by all the very sophisticated typing machinery of the
>> functional kernel of the language
>
>
> --
>
>
>
> *Ben Hutchison
> Senior Developer
> * Level 2 476 St Kilda Road Melbourne VIC 3004
> T 613 8807 5252 | F 613 8807 5203 | M 0423 879 534 |
> www.ibsglobalweb.com
>
>

• Actors may, in principle, enjoy a static typing discipline that derives from a types-for-concurrency approach.
• Scala "actors" do not, in practice, enjoy such a discipline. Scala "actors" do not really enjoy much connection with Hewitt-Agha style actors because of a lack of fair message delivery scheduling -- or even a statement of any discipline on the message delivery scheduling.
  

Hi Greg,

I'm intrigued by the contrast between your two statements about Actors and Static Typing copied below. The second one reflects my evaluation of Scala actors, so Im quite interested to see how you might better fit them into static typing - that's surely in the future of Actors.

I suspect you might have tried to explain that in the latter part of your letter, but I didn't understand it sufficiently. If you could give a more concrete example in Scala-like syntax, that would be interesting.

My present feeling is that Scala actors would best evolve towards a classic API, ie a set of named functions with typed parameters and return values. Invoking on an Actor shouldn't look so different from invoking on an Object, IMO. Jonas Boner blogged about some work in this area in Scala OTP [http://jonasboner.com/2008/12/11/real-world-scala-fault-tolerant-concurrent-asynchronous-components.html]. One difficulty is the way the a/synchronous divide gets papered over, but I'm not convinced that's unsurmountable.What's your opinion on this type of approach?

-Ben

Meredith Gregory wrote:

Actors represent an interesting sweet spot because they

...   - and turn out to fit into a static typing discipline
 

Meredith Gregory also wrote:

 Those familiar with Scala's
"actors" have certainly experienced a similar step over the edge, in the
sense that programming with Scala "actors" is not genuinely integrated with
or supported by all the very sophisticated typing machinery of the
functional kernel of the language

• (m arg0 arg1 ... argN) was syntax that resulted in the following evaluation
  
• send the message (m arg1 ... argN) to actor arg0;
  
• wait for a result and let that be the value of the expression
• (send m arg0 arg1 ... argN) was syntax that resulted in
  
• send the message (m arg1 ... argN) to actor arg0, but do not wait for results
• let #niv be the value of the expression (#niv is the constant representing no intrinsic value; it's like an untyped version of None in an Option, or maybe it might best be said to correspond to None for Option[Object])
  

• arg0.m(arg1 ,..., argN)
• arg0 ! m(arg1, ..., argN)

Ben,

Thanks for your query. To clarify the relationship between the two statements

• Actors may, in principle, enjoy a static typing discipline that derives from a types-for-concurrency approach.
• Scala "actors" do not, in practice, enjoy such a discipline. Scala "actors" do not really enjoy much connection with Hewitt-Agha style actors because of a lack of fair message delivery scheduling -- or even a statement of any discipline on the message delivery scheduling.
  

Given the plugin in scheduler architecture, if one plugs in the null scheduler that drops all work on the floor, is that a reasonable message delivery schedule? How does one specify what is reasonable? Without at least some specification of what is reasonable, there can be no static guarantees of any type. You could deploy code an enhanced types-for-concurrency type-checker guaranteed into a situation in which the null scheduler got plugged in -- by virtue of satisfying a long chain of dependencies for a large build for a Scala-based system -- and all bets would be off regarding what the code did. Of course, the null scheduler is really an extreme representative of a much more subtle problem. Getting scheduling policies correct can be a very tricky business.

Recently, i've been looking into Julia Lawall's Bossa as a possible mechanism for specifying a scheduling policy. One approach for a types-for-concurrency based approach to providing static checking for actors would be to state the guarantees up to a scheduling policy in Bossa. Then the type-checker would be off the hook if the code was deployed into a scheduler that violated the policy.

Best wishes,

--greg

On Mon, Aug 17, 2009 at 6:32 PM, Ben Hutchison <benh [at] ibsglobalweb [dot] com> wrote:

Hi Greg,

I'm intrigued by the contrast between your two statements about Actors and Static Typing copied below. The second one reflects my evaluation of Scala actors, so Im quite interested to see how you might better fit them into static typing - that's surely in the future of Actors.

I suspect you might have tried to explain that in the latter part of your letter, but I didn't understand it sufficiently. If you could give a more concrete example in Scala-like syntax, that would be interesting.

My present feeling is that Scala actors would best evolve towards a classic API, ie a set of named functions with typed parameters and return values. Invoking on an Actor shouldn't look so different from invoking on an Object, IMO. Jonas Boner blogged about some work in this area in Scala OTP [http://jonasboner.com/2008/12/11/real-world-scala-fault-tolerant-concurrent-asynchronous-components.html]. One difficulty is the way the a/synchronous divide gets papered over, but I'm not convinced that's unsurmountable.What's your opinion on this type of approach?

-Ben

Meredith Gregory wrote:

Actors represent an interesting sweet spot because they

...   - and turn out to fit into a static typing discipline
 

Meredith Gregory also wrote:

 Those familiar with Scala's
"actors" have certainly experienced a similar step over the edge, in the
sense that programming with Scala "actors" is not genuinely integrated with
or supported by all the very sophisticated typing machinery of the
functional kernel of the language

1. Make sure that the message I'm sending is understood by the recipient.
   
2. Make sure that each recipient processes all of the messages that might be sent to it.

I asked a similar question some time ago. Good answers were given:

http://www.nabble.com/-scala--Why-are-Scala's-actors-untyped--td18811476.html#a18811476

2009/8/18 David Melski :
> It's clear from the comments on scheduling that I'm out of my depth, here.
> But I only expect two simple things from "typed actors"
>
> Make sure that the message I'm sending is understood by the recipient.
> Make sure that each recipient processes all of the messages that might be
> sent to it.
>
> It is simple enough to wrap the existing actors so that one gets those two
> things, something like:
>
> sealed abstract class FooMsg
> ...
>
> class FooActor {
>   private val a = actor {
>     loop {
>       react {
>         case m: FooMsg => m match {
>           // exhausive match FooMsg (2)
>           case ...
>         }
>         case _ => throw new RuntimeException("Not a valid message")
>       }
>     }
>   }
>
>   // FooActors only take FooMsgs (1)
>   def ! (m: FooMsg) {a ! m}
> }
>
> and probably many other ways, which is great. It was just a bit odd that
> scala is so strongly typed, while actors use "Any" messages. Is this just
> because Scala actors are modeled on Erlang actors? Or is it because the
> untyped messages are desirable? For example, I imagine if you want to do
> some of Eralng's OTP tricks, like hot-swapping a running server, it might be
> important that you not limit the types of messages the server can receive.
>
> I'm also aware that a language like spec# has "contracts" that allow static
> specification of state machines that govern use of a channel. That would be
> significantly more complicated than my expectations, though also clearly
> useful.
>
> thanks,
> Dave
>
>

David Melski wrote:
> But I only expect two simple things from "typed actors"
>
> 1. Make sure that the message I'm sending is understood by the recipient.
> 2. Make sure that each recipient processes all of the messages that might
> be sent to it.
>
One more thing:

3. I dont want to have to rewrite code because I decide to change
component X's threading/execution model between "passive" and "active",
ie convert between an Object and an Actor.

OO programming is about objects sending messages to each other. Actor
programming is about Actors sending messages to each other. The
difference is that each Actor autonomously manages its own execution,
while Objects share a thread.

The fact that this aspect has leaked into invocation syntax is unfortunate.

I personally would never build a large software system over actors
without wrapping invocations in a typed, method-based API. I know that I
will want to change my mind about who the actors in the system are as I
go, and I dont wish to rewrite masses of code between eg:

emailService.sendEmail(...)
...and...
emailService ! SendEmail(...)

..just because email dispatch became asynchronous.

-Ben

> It is simple enough to wrap the existing actors so that one gets those two
> things, something like:
>
> sealed abstract class FooMsg
> ...
>
> class FooActor {
> private val a = actor {
> loop {
> react {
> case m: FooMsg => m match {
> // exhausive match FooMsg (2)
> case ...
> }
> case _ => throw new RuntimeException("Not a valid message")
> }
> }
> }
>
> // FooActors only take FooMsgs (1)
> def ! (m: FooMsg) {a ! m}
> }
>
> and probably many other ways, which is great. It was just a bit odd that
> scala is so strongly typed, while actors use "Any" messages. Is this just
> because Scala actors are modeled on Erlang actors? Or is it because the
> untyped messages are desirable? For example, I imagine if you want to do
> some of Eralng's OTP tricks, like hot-swapping a running server, it might be
> important that you not limit the types of messages the server can receive.
>
> I'm also aware that a language like spec# has "contracts" that allow static
> specification of state machines that govern use of a channel. That would be
> significantly more complicated than my expectations, though also clearly
> useful.
>
> thanks,
> Dave
>
>

It's clear from the comments on scheduling that I'm out of my depth, here. But I only expect two simple things from "typed actors"

1. Make sure that the message I'm sending is understood by the recipient.
   
2. Make sure that each recipient processes all of the messages that might be sent to it.

It is simple enough to wrap the existing actors so that one gets those two things, something like:

sealed abstract class FooMsg
...

class FooActor {
  private val a = actor {
    loop {
      react {
        case m: FooMsg => m match {
          // exhausive match FooMsg (2)
          case ...
        }
        case _ => throw new RuntimeException("Not a valid message")
      }
    }
  }

  // FooActors only take FooMsgs (1)
  def ! (m: FooMsg) {a ! m}
}

and probably many other ways, which is great. It was just a bit odd that scala is so strongly typed, while actors use "Any" messages. Is this just because Scala actors are modeled on Erlang actors? Or is it because the untyped messages are desirable? For example, I imagine if you want to do some of Eralng's OTP tricks, like hot-swapping a running server, it might be important that you not limit the types of messages the server can receive.

I'm also aware that a language like spec# has "contracts" that allow static specification of state machines that govern use of a channel. That would be significantly more complicated than my expectations, though also clearly useful.

thanks,
Dave

Dave,

How will wrapping an actor in an object ensure that a recipient processes all of the messages that might be sent to it. Specifically, are you claiming that wrapping an actor in an object will in all cases prevent the actor from deadlocking? If the actor is deadlocked, then even though the type of wrapping object says that the object can handle a message doesn't mean the actor is in a state that it can process the message. Perhaps your wrapper includes a timer on all message processing the actor does so that it's always in a race with a timeout that prevents potential deadlock?

case class Deadly( a : Actor ) {
   var gotSignal : Boolean = true

}

Best wishes,

--greg

On Tue, Aug 18, 2009 at 7:29 AM, David Melski <dgmelski [at] gmail [dot] com> wrote:

It's clear from the comments on scheduling that I'm out of my depth, here. But I only expect two simple things from "typed actors"

1. Make sure that the message I'm sending is understood by the recipient.
   
2. Make sure that each recipient processes all of the messages that might be sent to it.

It is simple enough to wrap the existing actors so that one gets those two things, something like:

sealed abstract class FooMsg
...

class FooActor {
  private val a = actor {
    loop {
      react {
        case m: FooMsg => m match {
          // exhausive match FooMsg (2)
          case ...
        }
        case _ => throw new RuntimeException("Not a valid message")
      }
    }
  }

  // FooActors only take FooMsgs (1)
  def ! (m: FooMsg) {a ! m}
}

and probably many other ways, which is great. It was just a bit odd that scala is so strongly typed, while actors use "Any" messages. Is this just because Scala actors are modeled on Erlang actors? Or is it because the untyped messages are desirable? For example, I imagine if you want to do some of Eralng's OTP tricks, like hot-swapping a running server, it might be important that you not limit the types of messages the server can receive.

I'm also aware that a language like spec# has "contracts" that allow static specification of state machines that govern use of a channel. That would be significantly more complicated than my expectations, though also clearly useful.

thanks,
Dave

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

Meredith Gregory wrote:
> How will wrapping an actor in an object ensure that a recipient processes
> all of the messages that might be sent to it.
Hi Greg,

I think David was alluding to the issue that if a message is sent to an
actor that its doesnt understand, the message will remain unmatched in
its mailbox indefinitely. A possible memory leak. Strongly typing actors
ensures they will be able to match on and thus consume any message that
can be sent to them via the typed client interface.

That's not to say that the issues you've mentioned re: lack of
scheduling semantics are resolved; I agree that they're not, and that
presently you just have to accept that pragmatically messages do happen
to get delivered "sometime" in the present implementation.

-Ben
> On Tue, Aug 18, 2009 at 7:29 AM, David Melski wrote:
>
>> But I only expect two simple things from "typed actors"
>>
>> 1. Make sure that the message I'm sending is understood by the
>> recipient.
>> 2. Make sure that each recipient processes all of the messages that
>> might be sent to it.
>>
>> It is simple enough to wrap the existing actors so that one gets those two
>> things, something like:
>>
>> sealed abstract class FooMsg
>> ...
>>
>> class FooActor {
>> private val a = actor {
>> loop {
>> react {
>> case m: FooMsg => m match {
>> // exhausive match FooMsg (2)
>> case ...
>> }
>> case _ => throw new RuntimeException("Not a valid message")
>> }
>> }
>> }
>>
>> // FooActors only take FooMsgs (1)
>> def ! (m: FooMsg) {a ! m}
>> }
>>
>> and probably many other ways, which is great. It was just a bit odd that
>> scala is so strongly typed, while actors use "Any" messages. Is this just
>> because Scala actors are modeled on Erlang actors? Or is it because the
>> untyped messages are desirable? For example, I imagine if you want to do
>> some of Eralng's OTP tricks, like hot-swapping a running server, it might be
>> important that you not limit the types of messages the server can receive.
>>
>> I'm also aware that a language like spec# has "contracts" that allow static
>> specification of state machines that govern use of a channel. That would be
>> significantly more complicated than my expectations, though also clearly
>> useful.
>>
>> thanks,
>> Dave
>>
>>
>>
>
>
>

2009/8/18 Ben Hutchison :
> Hi Greg,
>
> I'm intrigued by the contrast between your two statements about Actors and
> Static Typing copied below. The second one reflects my evaluation of Scala
> actors, so Im quite interested to see how you might better fit them into
> static typing - that's surely in the future of Actors.
>
> I suspect you might have tried to explain that in the latter part of your
> letter, but I didn't understand it sufficiently. If you could give a more
> concrete example in Scala-like syntax, that would be interesting.
>
> My present feeling is that Scala actors would best evolve towards a classic
> API, ie a set of named functions with typed parameters and return values.
> Invoking on an Actor shouldn't look so different from invoking on an Object,
> IMO. Jonas Boner blogged about some work in this area in Scala OTP
> [http://jonasboner.com/2008/12/11/real-world-scala-fault-tolerant-concurrent-asynchronous-components.html].
> One difficulty is the way the a/synchronous divide gets papered over, but
> I'm not convinced that's unsurmountable.What's your opinion on this type of
> approach?

FWIW, I've taken these ideas further in the Akka Project. Which is now
a production impl of both Actors and Active Objects addressing some of
the shortcomings in the Scala Actors library.

Read more here:
http://wiki.github.com/jboner/akka/reference-active-objects-java-api

>
> -Ben
>
> Meredith Gregory wrote:
>>
>> Actors represent an interesting sweet spot because they
>>
>> ...   - and turn out to fit into a static typing discipline
>>
>
> Meredith Gregory also wrote:
>>
>>  Those familiar with Scala's
>> "actors" have certainly experienced a similar step over the edge, in the
>> sense that programming with Scala "actors" is not genuinely integrated
>> with
>> or supported by all the very sophisticated typing machinery of the
>> functional kernel of the language
>
>
> --
>
>
>
> *Ben Hutchison
> Senior Developer
> * Level 2 476 St Kilda Road Melbourne VIC 3004
> T 613 8807 5252 | F 613 8807 5203 | M 0423 879 534 | www.ibsglobalweb.com
>
>
>
>

Meredith Gregory wrote:

How will wrapping an actor in an object ensure that a recipient processes
all of the messages that might be sent to it.

Hi Greg,

I think David was alluding to the issue that if a message is sent to an actor that its doesnt understand, the message will remain unmatched in its mailbox indefinitely. A possible memory leak. Strongly typing actors ensures they will be able to match on and thus consume any message that can be sent to them via the typed client interface.

That's not to say that the issues you've mentioned re: lack of scheduling semantics are resolved; I agree that they're not, and that presently you just have to accept that pragmatically messages do happen to get delivered "sometime" in the present implementation.

-Ben

On Tue, Aug 18, 2009 at 7:29 AM, David Melski <dgmelski [at] gmail [dot] com> wrote:
 

But I only expect two simple things from "typed actors"

  1. Make sure that the message I'm sending is understood by the
  recipient.
  2. Make sure that each recipient processes all of the messages that
  might be sent to it.

It is simple enough to wrap the existing actors so that one gets those two
things, something like:

sealed abstract class FooMsg
...

class FooActor {
 private val a = actor {
   loop {
     react {
       case m: FooMsg => m match {
         // exhausive match FooMsg (2)
         case ...
       }
       case _ => throw new RuntimeException("Not a valid message")
     }
   }
 }

 // FooActors only take FooMsgs (1)
 def ! (m: FooMsg) {a ! m}
}

and probably many other ways, which is great. It was just a bit odd that
scala is so strongly typed, while actors use "Any" messages. Is this just
because Scala actors are modeled on Erlang actors? Or is it because the
untyped messages are desirable? For example, I imagine if you want to do
some of Eralng's OTP tricks, like hot-swapping a running server, it might be
important that you not limit the types of messages the server can receive.

I'm also aware that a language like spec# has "contracts" that allow static
specification of state machines that govern use of a channel. That would be
significantly more complicated than my expectations, though also clearly
useful.

thanks,
Dave