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: 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