Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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