From: Kristof Bastiaensen <kristof@...>
Date: 2004-08-21T10:26:08+09:00
Subject: Re: ruby, actors, continuations, Kernel#callcc

On Sat, 21 Aug 2004 07:24:31 +0900, zuzu wrote:

> reading carl hewitt's seminal paper on the actor model:
> http://www.lcs.mit.edu/publications/specpub.php?id=762 my current
> impression is that actors are basically pure-OO objects using
> continuations (coroutines?) instead of stack-frame methods/subroutines.
> this way objects only require "promises" (in the form of the passing of
> context) rather than the final value (as with method stack-frames).  (i
> think this important towards breaking free from von neumann
> architecture, ala bachus:
> http://delivery.acm.org/10.1145/360000/359579/p613-backus.pdf?key1=359579&key2=7975779801&coll=portal&dl=ACM&CFID=11111111&CFTOKEN=2222222
> 
> but i still can't quite seem to grok continuations, at least in terms of
> interpreting it for ruby, w/r/t closures and Kernel#callcc.  this after
> reading dan "parrot" sugalski's weblog
> [http://www.sidhe.org/~dan/blog/], jim weirich's email
> [http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/78288 ],
> and rubygarden/c2.com/wikipedia articles on the subject:
> http://www.rubygarden.org/ruby?action=history&id=Continuations
> http://rubygarden.org/ruby?ContinuationExplanation
> http://www.ruby-doc.org/docs/ProgrammingRuby/html/ref_c_continuation.html
> http://c2.com/cgi/wiki?ContinuationExplanation
> http://en.wikipedia.org/wiki/Subroutine
> http://en.wikipedia.org/wiki/Coroutine
> 
> 
> any futher help is much appreciated.
> 
> thanks!
> 
> -z

Hi,

Here is how I think continuations and actor theory work together. This is
my interpretation, and it is possible I didn't get everything right, but I
hope it may help you.

I think the main problem in understanding continuations is that normally a
continuation is regarded as a function. However I think it is more the
other way around.  A function is more a special form of a continuation.

Let me try to explain a little.
Instead of looking at a program as a sequens of statements, you could
consider a program as many independend points (or actors), each which
takes a value, does something with it, and passes it to another point. You
could then call each such point a contination-point. (That is how I call
it, I don't really know if there is an official name). In the
actor-theory, this point would be an actor.

To be useful, the
continuation-point must also be aware of the current environment, and the
easiest way is to pass the environment from each point to another.  In the
actor-theory this environment could be just another actor, which could
respond to queries, for example to get a value.

A function would be a special kind of continuation-point, one that takes
in addition to the other values a continuation. This continuation will be
saved in the environment, and when the function has finished to do what it
has to do, it will send it's return value to the saved continuation.

How do closures and call/cc fit in this model?  You could say a closure is
a function and a saved environment. To call a closure, you get the saved
environment, and call the function with this environment, and any
parameters.  As described above, the function is a continuation-point that
accepts continuation, and calls this continuation will the final result.

However you could also save the environment for a continuation-point,
basicly creating a closure over the continuation-point.  This closure is
what is normally called a continuation.

call/cc just captures the next continuation (with the environment, which
includes any functions to return to), wraps it in an object, and calls the
given block with that object.  The continuation is actually that part of
the program that will receive the result from call/cc.  That result can be
either the value of the block, or the value passed to the
continuation-object (using "cont.call(value)").

I think the nice thing about actor theory is that it allows lambda
calculus to be implemented using parallel objects. You could build a chip,
where each continuation-point can be programmed in the chip, and would act
on its own.  This chip could the perform all the computations in parallel,
since each continuation point can act on it's own.  This would be
radically different from the current cpu-design, where there is only a
single point of controlflow.  A special sort of FPGA could be used for
this kind a chip, since they allow reprogramming on the fly.

Because lambda calculus is very basic to programming, it could be possible
to transform a traditional program into a form that makes maximum use of
parallelism in such a chip, and therefor be very fast.  Also all processes
that would fit into memory would run effectively parallel (not simulated
using task-switching), and wouldn't slow down any other process. It would
also support dynamic languages better, so that a ruby program wouldn't be
any slower that a C/C++ program.

I don't know if the design of such a chip would be possible, but it would
be a radically different aproach to computing.

Regards,
KB