[REBOL] Re: CPS transformations on func tion! values
From: brian::hawley::net at: 28-Feb-2003 13:52
At 09:49 PM 2/25/03 +0100, Maarten wrote:
>Now here is a puzzle....
>
>Has anybody given any thought to CPS transformation on function! values (
>a function! translator)? I did, but I can't figure out how to get all that
>dynamic code in tail-form :(
>
>Why?
>
>I'd like to be able to suspend my REBOL at any time, serialize it and the
>resume at some other time. Perhaps on another REBOL somewhere in the wild
>wild REB.
Sounds great, but you can't do this to a regular REBOL
process. REBOL is stack-based rather than continuation-
based since 1.9, so saving a continuation would require
reading the stack (how do you do this?) and resuming one
would require writing to the stack directly, with an as-
yet nonexistent native. Basically it would be easier to
write your own continuation-based interpreter.
On the other hand, I have written continuation-passing
code in REBOL in a previous project, in a section that
provided facilities similar to Rugby. This was before
Rugby came out, not nearly as good and not published,
but it worked well enough.
The relevant function consumed a list of blocks, each
block a statement of REBOL code that I referred to as an
event, usually a function call. Each event function did
a part of a task then returned the next event to be done
in the task, which the event handler appended on to the
event list. When an event completed a task it returned
none. The point of this was to implement cooperative
multitasking, but I could have easily saved the event
list and loaded it later if I needed to (I didn't).
Because the current state of a task needed to be stored
in a single event block (no stack, no history), events
were written in a continuation-passing style.
What I didn't do is write code that CPS-transformed the
REBOL code for me. That would have required a semantic
model for REBOL in continuation form, and I didn't have
time to make one. It was quicker to break up the code
by hand. YMMV.
>Why?
>
>Think parallelized computations. Think GRID computing. Think Information
>World (yes Gabriele, I haven't forgotten).
If you use your existing Rugby facilities you should
be able to rig up a Linda-style event server. Clients
would then post events to the server, nodes would then
grab and handle events, posting subsequent events if
necessary. Kinda old-school compared to the grid model
but it could still work.
>Storing the state of a REBOL is easy if you mark some types (port! native!
>as volatile) and do dome tricks on others (most notably those use values).
Aaack. Most of the work I do with REBOL is on those
volatile types, making it quite unsuitable for this
kind of distributed computing. The closest I come is
with applications similar to BitTorrent.
- Brian