Leopold Toetsch <[EMAIL PROTECTED]> writes: > Dan Sugalski <[EMAIL PROTECTED]> wrote: >> At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote: >>> >>>Which brings up again my warnocked question: How can return >>>continuations get reused? > >> Works like this. (No pasm, but it should be obvious) > > Ok. First (and that applies to Jens example too), I'd like to outline > continuation vs return continuation and its usage: > > 1) First there was only a Continuation PMC. Performance with CPS sucked. > So I did invent a RetContinuation PMC Performance sucked less. The > difference between these two is: the former has COW copied stacks inside > its context, the latter has only pointers of the stacks in its context. > > 2) A return continuation is automatically created by > > invokecc > callmethodcc > > It's totally hidden when using PIR function or method call syntax > > _func(a, b) > obj."meth"(args) > > These internally create above opcodes and create a new return > continuation on each sub or method invocation > > 3) Returning from the sub or method in PIR syntax again totally hides > the return continuation > > .pcc_begin_return > .return result > .pcc_end_return > .end > > or just > > .sub _foo > .end # automatic return sequence inserted. > > 4) From PIR level there is no official way to even reference this return > continuation - its invisible. > > 5) *But* > >> If a continuation's taken from within a sub somewhere, return >> continuations may (probably will) be used multiple times, once for >> the original return then once for each time the continuation is >> invoked. > > 6) Yes, that's true. So the questios is: Can we invent some HLL PIR > syntax that clearly indicates: this subroutine will return multiple > times through the same return continuation. We have already a similar > construct for Coroutines: > > .pcc_begin_yield > .result # optional > .pcc_end_yield > > This is invokeing the coroutine and returns to the caller. > > What's the usage of Continuations from HLLs point of view? Can we get > some hints, what is intended? > > I'd like to have, if possible a clear indication: that's a plain > function or method call and this is not. I think the possible speedup is > worth the effort.
I think that requires solving the halting problem.
