This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Type signature of loopWhile in actors library

4 replies
Olivier Pernet 2
Joined: 2010-12-03,
User offline. Last seen 42 years 45 weeks ago.

Hi all,

I just noticed the following oddity:

> val a = actor {
var received=false
loopWhile(!received) {
receive { case x => println(x); received=true }
println("end")
}
}
> a ! "foo"
foo
end

> val a = actor {
var received=false
loopWhile(!received) {
react { case x => println(x); received=true }
println("end")
}
}
> a ! "foo"
foo

Notice no "end" in the second case.
Should loopWhile not return Nothing instead of Unit to prevent this
from compiling?

Olivier

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Type signature of loopWhile in actors library
Ah, so you've run into the fun that is the actors implementation.
Actors are implemented as continuations.  Anything after "react" will not occur because receive throws an exception which the actors implementation catches (after registering your message handler with the system).
This is a tricky way of doing continuation-based programming with Actors (and ensuring the current thread is not blocked by the react call).  
When using react, you most always explicitly call the next portion of behavior to run after processing a message.  The loop and loopWhile methods do this for you.
- Josh
On Mon, Apr 4, 2011 at 1:21 PM, Olivier Pernet <o.pernet@gmail.com> wrote:
Hi all,

I just noticed the following oddity:

> val a = actor {
 var received=false
 loopWhile(!received) {
   receive { case x => println(x); received=true }
   println("end")
 }
}
> a ! "foo"
foo
end

> val a = actor {
 var received=false
 loopWhile(!received) {
   react { case x => println(x); received=true }
   println("end")
 }
}
> a ! "foo"
foo

Notice no "end" in the second case.
Should loopWhile not return Nothing instead of Unit to prevent this
from compiling?

Olivier

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Type signature of loopWhile in actors library
Second line should read:

 Anything after "react" will not occur because react throws an exception which the actors implementation catches (after registering your message handler with the system).

On Mon, Apr 4, 2011 at 2:36 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
Ah, so you've run into the fun that is the actors implementation.
Actors are implemented as continuations.  Anything after "react" will not occur because receive throws an exception which the actors implementation catches (after registering your message handler with the system).
This is a tricky way of doing continuation-based programming with Actors (and ensuring the current thread is not blocked by the react call).  
When using react, you most always explicitly call the next portion of behavior to run after processing a message.  The loop and loopWhile methods do this for you.
- Josh
On Mon, Apr 4, 2011 at 1:21 PM, Olivier Pernet <o.pernet@gmail.com> wrote:
Hi all,

I just noticed the following oddity:

> val a = actor {
 var received=false
 loopWhile(!received) {
   receive { case x => println(x); received=true }
   println("end")
 }
}
> a ! "foo"
foo
end

> val a = actor {
 var received=false
 loopWhile(!received) {
   react { case x => println(x); received=true }
   println("end")
 }
}
> a ! "foo"
foo

Notice no "end" in the second case.
Should loopWhile not return Nothing instead of Unit to prevent this
from compiling?

Olivier


Olivier Pernet 2
Joined: 2010-12-03,
User offline. Last seen 42 years 45 weeks ago.
Re: Type signature of loopWhile in actors library

Right, I realize that's the way it works.
I was just suggesting that we make loopWhile (and loop as well) return
Nothing instead of Unit,
to be consistent with react.

Actually, I thought the change would make my example fail
typechecking, but I just made a little experiment and it seems it
would not.
But then, why have react return Nothing?

As an aside, are there plans to use continuations instead of the
current exceptions trick to implement react? That would be nicer...

Olivier

On Mon, Apr 4, 2011 at 19:36, Josh Suereth wrote:
> Second line should read:
>
>  Anything after "react" will not occur because react throws an exception
> which the actors implementation catches (after registering your message
> handler with the system).
>
> On Mon, Apr 4, 2011 at 2:36 PM, Josh Suereth
> wrote:
>>
>> Ah, so you've run into the fun that is the actors implementation.
>> Actors are implemented as continuations.  Anything after "react" will not
>> occur because receive throws an exception which the actors implementation
>> catches (after registering your message handler with the system).
>> This is a tricky way of doing continuation-based programming with Actors
>> (and ensuring the current thread is not blocked by the react call).
>> When using react, you most always explicitly call the next portion of
>> behavior to run after processing a message.  The loop and loopWhile methods
>> do this for you.
>> - Josh
>> On Mon, Apr 4, 2011 at 1:21 PM, Olivier Pernet wrote:
>>>
>>> Hi all,
>>>
>>> I just noticed the following oddity:
>>>
>>> > val a = actor {
>>>  var received=false
>>>  loopWhile(!received) {
>>>    receive { case x => println(x); received=true }
>>>    println("end")
>>>  }
>>> }
>>> > a ! "foo"
>>> foo
>>> end
>>>
>>> > val a = actor {
>>>  var received=false
>>>  loopWhile(!received) {
>>>    react { case x => println(x); received=true }
>>>    println("end")
>>>  }
>>> }
>>> > a ! "foo"
>>> foo
>>>
>>> Notice no "end" in the second case.
>>> Should loopWhile not return Nothing instead of Unit to prevent this
>>> from compiling?
>>>
>>> Olivier
>>
>
>

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Type signature of loopWhile in actors library
Phillip and Tiark included a really interesting way to construct actors using continuations in the continuations paper:
http://lamp.epfl.ch/~rompf/continuations-icfp09.pdf
See pages 8 and 9.
For alternative actor implementation with less expressiveness in handling messages, but far more robustness see Akka.
- Josh

On Tue, Apr 5, 2011 at 11:36 AM, Olivier Pernet <o.pernet@gmail.com> wrote:
Right, I realize that's the way it works.
I was just suggesting that we make loopWhile (and loop as well) return
Nothing instead of Unit,
to be consistent with react.

Actually, I thought the change would make my example fail
typechecking, but I just made a little experiment and it seems it
would not.
But then, why have react return Nothing?

As an aside, are there plans to use continuations instead of the
current exceptions trick to implement react? That would be nicer...

Olivier


On Mon, Apr 4, 2011 at 19:36, Josh Suereth <joshua.suereth@gmail.com> wrote:
> Second line should read:
>
>  Anything after "react" will not occur because react throws an exception
> which the actors implementation catches (after registering your message
> handler with the system).
>
> On Mon, Apr 4, 2011 at 2:36 PM, Josh Suereth <joshua.suereth@gmail.com>
> wrote:
>>
>> Ah, so you've run into the fun that is the actors implementation.
>> Actors are implemented as continuations.  Anything after "react" will not
>> occur because receive throws an exception which the actors implementation
>> catches (after registering your message handler with the system).
>> This is a tricky way of doing continuation-based programming with Actors
>> (and ensuring the current thread is not blocked by the react call).
>> When using react, you most always explicitly call the next portion of
>> behavior to run after processing a message.  The loop and loopWhile methods
>> do this for you.
>> - Josh
>> On Mon, Apr 4, 2011 at 1:21 PM, Olivier Pernet <o.pernet@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> I just noticed the following oddity:
>>>
>>> > val a = actor {
>>>  var received=false
>>>  loopWhile(!received) {
>>>    receive { case x => println(x); received=true }
>>>    println("end")
>>>  }
>>> }
>>> > a ! "foo"
>>> foo
>>> end
>>>
>>> > val a = actor {
>>>  var received=false
>>>  loopWhile(!received) {
>>>    react { case x => println(x); received=true }
>>>    println("end")
>>>  }
>>> }
>>> > a ! "foo"
>>> foo
>>>
>>> Notice no "end" in the second case.
>>> Should loopWhile not return Nothing instead of Unit to prevent this
>>> from compiling?
>>>
>>> Olivier
>>
>
>

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland