[Python-Dev] 'stackless' python?

Guido van Rossum guido@CNRI.Reston.VA.US
Tue, 18 May 1999 00:03:34 -0400

Sam (& others),

I thought I understood what continuations were, but the examples of
what you can do with them so far don't clarify the matter at all.

Perhaps it would help to explain what a continuation actually does
with the run-time environment, instead of giving examples of how to
use them and what the result it?

Here's a start of my own understanding (brief because I'm on a 28.8k
connection which makes my ordinary typing habits in Emacs very

1. All program state is somehow contained in a single execution stack.
This includes globals (which are simply name bindings in the botton
stack frame).  It also includes a code pointer for each stack frame
indicating where the function corresponding to that stack frame is
executing (this is the return address if there is a newer stack frame, 
or the current instruction for the newest frame).

2. A continuation does something equivalent to making a copy of the
entire execution stack.  This can probably be done lazily.  There are
probably lots of details.  I also expect that Scheme's semantic model
is different than Python here -- e.g. does it matter whether deep or
shallow copies are made?  I.e. are there mutable *objects* in Scheme?
(I know there are mutable and immutable *name bindings* -- I think.)

3. Calling a continuation probably makes the saved copy of the
execution stack the current execution state; I presume there's also a
way to pass an extra argument.

4. Coroutines (which I *do* understand) are probably done by swapping
between two (or more) continuations.

5. Other control constructs can be done by various manipulations of
continuations.  I presume that in many situations the saved
continuation becomes the main control locus permanently, and the
(previously) current stack is simply garbage-collected.  Of course the 
lazy copy makes this efficient.

If this all is close enough to the truth, I think that continuations
involving C stack frames are definitely out -- as Tim Peters
mentioned, you don't know what the stuff on the C stack of extensions
refers to.  (My guess would be that Scheme implementations assume that
any pointers on the C stack point to Scheme objects, so that C stack
frames can be copied and conservative GC can be used -- this will
never happen in Python.)

Continuations involving only Python stack frames might be supported,
if we can agree on the the sharing / copying semantics.  This is where 
I don't know enough see questions at #2 above).

--Guido van Rossum (home page: http://www.python.org/~guido/)