Python 2.0 and Stackless

[Gordon McMillan]

[posted and mailed]

Vladimir Marangozov wrote: 

>Gordon McMillan wrote:
>> 
>> [me, arguing that an execution stack preserves strict frame
>>  ordering, while a graph of frames does not]
>> >
>> >But it is also a fact that by removing the stack you lose its
>> >benefits. So full (functional) compatibility is *not* there.
>> 
>> I'd grant you the first sentence if I thought stacks *had* any
>> functional benefits over graphs. But the only benefit I know of is
>> simplicity at the price of reduced functionality. After all, a stack
>> is just a special case of a graph.
>
>Are you kidding? 

About what?

>What about cycles in the graph?

AFAIK, it doesn't happen. Maybe with sufficient perversion you can make it 
happen.

>Does Stackless create a new frame when we jump to an already visited
>code, in which case it piles them up by emulating the stack?
>(Note: I haven't looked at Christian's code for a while).

If you take an exception, you'll see that there's always a "stack" (in the 
sense of a path back to the root). If continuation1 calls continuation2 
which calls continuation1 again, you'll quickly take an exception. One (or 
both, if you're doing continuations and not coroutines) of those should be 
a jump. If you restart a continuation, you get a copy (if there are 
outstanding references to the old one).

>If not, would the cycle be eligible for cyclic garbage collection?
><wink> 

It's easy in naive usage of continuations to create leaks. Both Just and I 
have found one situation in which we can't seem to avoid the leak, and I 
know (the long-silent) Christian is looking at this. But otherwise, it 
appears possible to have all the power of coroutines and continuations 
without cycles / leaks.

This isn't always easy, but threads weren't easy until a higher level 
module was written, either.

>These concerns deserve to be addressed in a PEP!

These concerns are addressed by the code. What needs to addressed:
 - possible conflicts with GC
 - possible confilcts with other changes to ceval.c
 - ways to make it easier to use 

Personally, I think a coroutine interface is needed. It's fine with me if 
the continuation interface continues to be arcane - that's the nature of 
continuations. But coroutines are graspable even by people who think that 
"call" is not decomposable. I've been using stackless heavily since May, 
and everything I've done with it (except some experiments) qualifies as 
coroutines. Christian & I have talked about the patterns we've each used 
for this stuff, and I hope a friendly interface will grow out of it.

But there's really no sense in proposing that which already exists.

- Gordon