[REBOL] Re: CPS transformations on func tion! values
From: maarten:koopmans:surfnet:nl at: 1-Mar-2003 13:10
> 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.
>
You can to a certain degree if you intercept the evaluation within a
function call (a stack frame) and create functions in tail-form. The
problem is all the dynamic code like reduce [ .. ] and do [ .. ]
How do you transform that?
> 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.
>
This sounds a bit like the Rugby task engine. But I'd like to move
beyond that.
> 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.
>
I have difficulty creating that model (hence my post).
>> 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.
>
You can even do better than that, but it requires significant work from
the programmer. With a fully reflexive language we should be able to do
better.
Rugby has features like "chaining" where a call on a server is
redirected to another node (the idea was to easily allow P2P searches
and stuff), but, but....
>> 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.
>
But you can override all the I/O functions and add you own IO
virtualization layer then.
Sigh. Lots of thinking to do. Thanks anyway....
--Maarten
