Jeff Clites <[EMAIL PROTECTED]> wrote: > On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
>> Yes, but Jeff's example wasn't really reflecting the problem. > How come? Your code didn't reuse C<a> after the call. > ... It seems > that even this function body shows the problem: Yes, that one is reflecting it. > a = 1 > foo() > print a > b = 10 > return b > It would seem (w/o continuations) that b should be able to re-use a's > register, but if it does then we'll print 10 instead of 1 "the second > time". Yep, if there is another call that uses the captured continuation of the foo() call and continues at "print a". > It seems that, in term of cache locality, the same problem is there > with more registers v. spilling v. lexicals. Not quite. We can't extend just one register set, we'd do that for all 4 kinds. You can not easily have 64 PMC registers and just 10 INTVALs. A lexical access is just an array lookup (at least if the compiler uses the indexed addressing of lexicals). > ... That is, if you have 100 > local variables whose lifetimes overlap (due to continuations), then > you need 100 distinct memory locations to (repeatedly) access. Sure. If the program is complex you need the storage anyway. >> 4) Having an explicit syntax construct "(call-with-current-continuation >> " that expresses verbatim, what's going on, like e.g. with a reserved >> word placed as a label: >> >> RESUMEABLE: x = choose(arr1) > I don't think that really helps either: If you have such a call, then > all the frames higher up the stack also can "return multiple times", so > they have the behavior, even w/o the label. The RESUMABLE label is of course at the invocation that might resume, somehwere up the call chain. Again: the HLL compiler (or the programmer) knows the effect of the continuation. Just the PIR code is too dumb, i.e. is lacking this information. > On the other hand, this Ruby code really bugs me (note: "$" variables > in Ruby are globals): > ... , you get an infinite loop, printing increasing > integers.) Sure. With callcc you are calling the function again and again. > JEff leo
