- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Type signature of loopWhile in actors library
Mon, 2011-04-04, 18:21
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
Mon, 2011-04-04, 19:47
#2
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:
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
Tue, 2011-04-05, 16:37
#3
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
>>
>
>
Tue, 2011-04-05, 19:07
#4
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:
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
>>
>
>
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: