Query regarding models of concurrent computation

How does this differ from

  react {
    case msg: pattern if cond(msg) => handle(msg)
  }

?

I thought this was exactly what partial matches were for.

Or is the benefit that you have a clear termination condition, which takes a little more work with the above?

  --Rex

On Fri, Dec 16, 2011 at 2:31 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?
for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Greg's proposal is monadic and much more natural to me than the react one. Thus it would implicitly reveal the benefits of monads and greater composability. I definitely think that this proposal makes a lot of sense.

Marius

On Dec 16, 2011 10:24 PM, "Rex Kerr" <ichoran [at] gmail [dot] com> wrote:

How does this differ from

  react {
    case msg: pattern if cond(msg) => handle(msg)
  }

?

I thought this was exactly what partial matches were for.

Or is the benefit that you have a clear termination condition, which takes a little more work with the above?

  --Rex

On Fri, Dec 16, 2011 at 2:31 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?
for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

+1

--
Jim Powers

On Dec 16, 2011 6:15 PM, "Marius Danciu" <marius [dot] danciu [at] gmail [dot] com> wrote:

Greg's proposal is monadic and much more natural to me than the react one. Thus it would implicitly reveal the benefits of monads and greater composability. I definitely think that this proposal makes a lot of sense.

Marius

On Dec 16, 2011 10:24 PM, "Rex Kerr" <ichoran [at] gmail [dot] com> wrote:

How does this differ from

  react {
    case msg: pattern if cond(msg) => handle(msg)
  }

?

I thought this was exactly what partial matches were for.

Or is the benefit that you have a clear termination condition, which takes a little more work with the above?

  --Rex

On Fri, Dec 16, 2011 at 2:31 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?
for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

On Fri, Dec 16, 2011 at 6:15 PM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com> wrote:

Greg's proposal is monadic and much more natural to me than the react one. Thus it would implicitly reveal the benefits of monads and greater composability. I definitely think that this proposal makes a lot of sense.

I was hoping for an outline of a use-case, not a statement of purported advantages of monads in an abstract context.

For example, if you want to do redundancy elimination (e.g. if you get a message that tells you to switch to state A, and then another that tells you to switch to state B, you may be able to switch to B directly), the current react system's single-message-at-a-time mode makes one write weird recursive code to accomplish this.  You _might_ be able to handle this elegantly with a standing query, but it depends very much on what the model is.  The "get" suggests "Option-like" not "List-like" to me, which suggests "single item", which suggests "I've already got that with react pattern matching--what does it let me do easily (that I am likely to want to do) that I couldn't do before?".

Partial functions are composable too, you know.

  --Rex
 

Marius

On Dec 16, 2011 10:24 PM, "Rex Kerr" <ichoran [at] gmail [dot] com> wrote:

How does this differ from

  react {
    case msg: pattern if cond(msg) => handle(msg)
  }

?

I thought this was exactly what partial matches were for.

Or is the benefit that you have a clear termination condition, which takes a little more work with the above?

  --Rex

On Fri, Dec 16, 2011 at 2:31 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?
for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Yes partial functions can be composed yes up to a certain point, but that's beside the topic I think. Messages themselves can be non trivial structures.
The above  for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) } 
could probably be
for( SomeMsg(msg) <- mbox.get; if ( cond( msg ) ) ) { handle( msg ) } 

as  pattern matching goes there.
So if the message itself is a monadic structure one could do:
for( SomeMsg(msg) <- mbox.get; if ( cond( msg )       extract <- msg) yield {    handle( msg )} 
// I know that Greg did not use for comprehensions but I think they could fit nicely.
The correspondent would be :
react {  case SomeMsg(msg) => for (extract <- msg) { handle(msg) }}
I find the first one more elegant than the react one ... but its really a taste thing. I don't think anyone suggests replacing react. Erlang style is definitely a good thing, but it doesn't mean that other models are not suitable for dealing with async messages.
Marius

On Sat, Dec 17, 2011 at 6:21 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

On Fri, Dec 16, 2011 at 6:15 PM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com> wrote:

Greg's proposal is monadic and much more natural to me than the react one. Thus it would implicitly reveal the benefits of monads and greater composability. I definitely think that this proposal makes a lot of sense.

I was hoping for an outline of a use-case, not a statement of purported advantages of monads in an abstract context.

For example, if you want to do redundancy elimination (e.g. if you get a message that tells you to switch to state A, and then another that tells you to switch to state B, you may be able to switch to B directly), the current react system's single-message-at-a-time mode makes one write weird recursive code to accomplish this.  You _might_ be able to handle this elegantly with a standing query, but it depends very much on what the model is.  The "get" suggests "Option-like" not "List-like" to me, which suggests "single item", which suggests "I've already got that with react pattern matching--what does it let me do easily (that I am likely to want to do) that I couldn't do before?".

Partial functions are composable too, you know.

  --Rex
 

Marius

On Dec 16, 2011 10:24 PM, "Rex Kerr" <ichoran [at] gmail [dot] com> wrote:

How does this differ from

  react {
    case msg: pattern if cond(msg) => handle(msg)
  }

?

I thought this was exactly what partial matches were for.

Or is the benefit that you have a clear termination condition, which takes a little more work with the above?

  --Rex

On Fri, Dec 16, 2011 at 2:31 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?
for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Sounds like an Erlang-style selective receive, which is commonly known to be the biggest contributor to performance problems in Erlang programs.

YMMV

Cheers,
√

On Sat, Dec 17, 2011 at 5:21 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

On Fri, Dec 16, 2011 at 6:15 PM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com> wrote:

Greg's proposal is monadic and much more natural to me than the react one. Thus it would implicitly reveal the benefits of monads and greater composability. I definitely think that this proposal makes a lot of sense.

I was hoping for an outline of a use-case, not a statement of purported advantages of monads in an abstract context.

For example, if you want to do redundancy elimination (e.g. if you get a message that tells you to switch to state A, and then another that tells you to switch to state B, you may be able to switch to B directly), the current react system's single-message-at-a-time mode makes one write weird recursive code to accomplish this.  You _might_ be able to handle this elegantly with a standing query, but it depends very much on what the model is.  The "get" suggests "Option-like" not "List-like" to me, which suggests "single item", which suggests "I've already got that with react pattern matching--what does it let me do easily (that I am likely to want to do) that I couldn't do before?".

Partial functions are composable too, you know.

  --Rex
 

Marius

On Dec 16, 2011 10:24 PM, "Rex Kerr" <ichoran [at] gmail [dot] com> wrote:

How does this differ from

  react {
    case msg: pattern if cond(msg) => handle(msg)
  }

?

I thought this was exactly what partial matches were for.

Or is the benefit that you have a clear termination condition, which takes a little more work with the above?

  --Rex

On Fri, Dec 16, 2011 at 2:31 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?
for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Dear Optimistically Concurrent,
Thanks for this lively thread!
i really appreciate Rex's question. That's a good one. To my mind, after we did Rosette, and then used it on many industrial applications, one of the biggest issues i had with actors was simultaneous coordination of messages across ports. The "take action when these events all occur on these separate ports, and these constraints are met" pattern that shows up in many use cases, is much more heavy weight in the actor model. So, let's look at how this scales in the monadic (since Marius named it!) setting.
for( event1 <- mbox1.get( pattern1 ); ...; eventN <- mboxN.get( patternN ); if ( cond( event1, ..., eventK ) ) ) {   handle( event1, ..., eventN )}
That looks very concise! Now, one issue that arises is searching these event streams (the various mboxes) for events that match the patterns and constraints. This is an issue of interleaving of streams and putting events back when they don't match. This requires some relatively delicate machinery. Fascinatingly, Kiselyov, Shan, Friedman and Sabry, give a very nice monadic presentation (i've given a transliteration to scala here). So, the monadic presentation not only supports cross-port coordination, but also provides a DSL for expressing the fair-interleaving patterns for a given application domain.
The smallest example is a trading application with real (enough) time ask and bid streams.
for( ask <- askMbox.get( askPattern ); bid <- bidMbox.get( bidPattern ); if ( cond( ask, bid ) ) ) {    trade( ask, bid )}
More realistic versions will monitor other streams, such as other market events, interest changes, trading windows, model drift, etc.
The crucial point is that monadic pattern scales nicely along with the complexity of the use case. How does the react pattern scale correspondingly?

Best wishes,
--greg

2011/12/17 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>

Sounds like an Erlang-style selective receive, which is commonly known to be the biggest contributor to performance problems in Erlang programs.

YMMV

Cheers,
√

On Sat, Dec 17, 2011 at 5:21 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

On Fri, Dec 16, 2011 at 6:15 PM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com> wrote:

Greg's proposal is monadic and much more natural to me than the react one. Thus it would implicitly reveal the benefits of monads and greater composability. I definitely think that this proposal makes a lot of sense.

I was hoping for an outline of a use-case, not a statement of purported advantages of monads in an abstract context.

For example, if you want to do redundancy elimination (e.g. if you get a message that tells you to switch to state A, and then another that tells you to switch to state B, you may be able to switch to B directly), the current react system's single-message-at-a-time mode makes one write weird recursive code to accomplish this.  You _might_ be able to handle this elegantly with a standing query, but it depends very much on what the model is.  The "get" suggests "Option-like" not "List-like" to me, which suggests "single item", which suggests "I've already got that with react pattern matching--what does it let me do easily (that I am likely to want to do) that I couldn't do before?".

Partial functions are composable too, you know.

  --Rex
 

Marius

On Dec 16, 2011 10:24 PM, "Rex Kerr" <ichoran [at] gmail [dot] com> wrote:

How does this differ from

  react {
    case msg: pattern if cond(msg) => handle(msg)
  }

?

I thought this was exactly what partial matches were for.

Or is the benefit that you have a clear termination condition, which takes a little more work with the above?

  --Rex

On Fri, Dec 16, 2011 at 2:31 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?
for( msg <- mbox.get( pattern ); if ( cond( msg ) ) ) { handle( msg ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

2011/12/17 Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com>

The smallest example is a trading application with real (enough) time ask and bid streams.
for( ask <- askMbox.get( askPattern ); bid <- bidMbox.get( bidPattern ); if ( cond( ask, bid ) ) ) {    trade( ask, bid )}

Ah, that's potentially interesting--but where do these various mboxes come from?  I have solved problems like this in the past by something like what's described in
  http://www.scala-lang.org/docu/files/actors-api/actors_api_guide_2.html
in the actors guide:

  { react {
    case x: Ask => askbox enqueue x
    case y: Bid => bidbox enqueue y
    case _ => // Handle this sanely
  }: Unit} andThen {
    for (
      x <- askbox find askPattern
      y <- bidbox find bidPattern
      if (cond(x,y))
    ) {
      trade(x,y)
      askbox -= x
      bidbox -= y
    }
  }
   
where here I'm explicitly disposing of the resources.  If I get many different classes of messages, then instead I put the for part in some other method and

    react {
      case x: Ask => askbox enqueue x; tryToTrade
      ...
      case w: Whatever => what enqueue w; tryToSomething
      ...
    }

So I think the key issue is how those mailboxes get generated, since one can already make them by hand explicitly.

(I am assuming that the proposal is _not_ for cross-actor coordination, which requires a fair bit more thought, but only for coordination within one actor.)

  --Rex

Dear Rex,
Fantastic! i think your note hits right on the salient points! First, in regard to your clarifying question at the end: when i encountered Robin's π-calculus -- which came after we had years of experience developing Rosette and using in applications -- the first insight i had was in the form of a question: Why does internal actor coordination have to differ from actor-to-actor coordination? Is it possible to have both a theoretical and pragmatic programming model in which these phenomena could be treated uniformly?
Your other point regarding where do the mboxes originate is also right on the money -- for my money, anyway. ;-) The possibility exists that the event streams may be conflated with the mbox. More specifically, the idea is to virtualize the mbox as a standing query against an event stream -- this is really what you are doing in your code -- but with no syntactic support at the outer layer. Taking advantages of a more uniformly monadic approach seems somewhat promising in that flatMap -- plus a monadic approach to backtracking -- provides a way to scale this across event streams with fair interleaving.
Now, Viktor's observation about performance is quite interesting. i would ask what are current best practices regarding highest performance for the multi-stream coordination use case? Obviously, in the case where we have no interaction, it's fairly easy to parallelize and scale horizontally. My experience is that all the really useful stuff comes about because of varieties of interaction across data streams. This is certainly true in biological applications and in many enterprise applications. In the days post web 2.0 this seems to become more the norm. We want to see interaction across many streams of data. So, what are best practices? How do they scale performance-wise, and how do they scale complexity-wise? (My own tendency -- from years of practice -- is to sort out the complexity component, first, and then allow the performance aspect to sort itself out. This is not always best, but it is a rough rule of thumb that has served well in the past.)
Best wishes,
--greg

On Sun, Dec 18, 2011 at 3:57 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

2011/12/17 Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com>

The smallest example is a trading application with real (enough) time ask and bid streams.
for( ask <- askMbox.get( askPattern ); bid <- bidMbox.get( bidPattern ); if ( cond( ask, bid ) ) ) {    trade( ask, bid )}

Ah, that's potentially interesting--but where do these various mboxes come from?  I have solved problems like this in the past by something like what's described in
  http://www.scala-lang.org/docu/files/actors-api/actors_api_guide_2.html
in the actors guide:

  { react {
    case x: Ask => askbox enqueue x
    case y: Bid => bidbox enqueue y
    case _ => // Handle this sanely
  }: Unit} andThen {
    for (
      x <- askbox find askPattern
      y <- bidbox find bidPattern
      if (cond(x,y))
    ) {
      trade(x,y)
      askbox -= x
      bidbox -= y
    }
  }
   
where here I'm explicitly disposing of the resources.  If I get many different classes of messages, then instead I put the for part in some other method and

    react {
      case x: Ask => askbox enqueue x; tryToTrade
      ...
      case w: Whatever => what enqueue w; tryToSomething
      ...
    }

So I think the key issue is how those mailboxes get generated, since one can already make them by hand explicitly.

(I am assuming that the proposal is _not_ for cross-actor coordination, which requires a fair bit more thought, but only for coordination within one actor.)

  --Rex

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com