Fake threads (was [Python-Dev] ActiveState & fork & Perl)

[Mark Hammond]

> NOW
 No problems, fine sailing...

> GENERATORS

Cruising along - nice day to be out!

> COROUTINES

Such a pleasant day!


> CONTINUATIONS

Are they clouds I see?

> Given the pedagogical structure so far, you're primed to view
> continuations
> as an enhancement of coroutines.  And that's exactly what will get you
> nowhere <wink>.  Continuations aren't more elaborate than coroutines,
> they're simpler.  Indeed, they're simpler than generators,

A storm warning...

> Legend has it they were discovered when theorists were trying
> to find a
> solid reason for why goto statements suck:  the growth of
> "denotational
> semantics" (DS) boomed at the same time "structured
> programming" took off.
> The former is a solid & fruitful approach to formally specifying the

She's taking on water!

> In theory a continuation is a function that computes "the rest of the
> program", or "its future".

OK - before I abandon ship, I might need my hand-held.  Before I start, let
me echo Skip and Barry - and excellent precis of a topic I knew nothing
about (as I made you painfully aware!)  And I will avoid asking you to
explain the above paragraph again for now :-)

Im a little confused by how these work in practice.  I can see how
continuations provide the framework to do all these control things.

It is clear to me how you can capture the "state" of a running program.
Indeed, this is exactly what it seems generators and coroutines do.

With continuations, how is the state captured or created?  Eg, in the case
of implementing a goto or a function call, there doesnt seem to be to be a
state available.  Does the language supporting continuations allow you to
explicitely create one from any arbitary position?  I think you sort-of
answered that below:

> Anyway, in implementation terms a continuation "is like" what
> a coroutine
> would be if you could capture its resumption state at any point (even
> without the coroutine's knowledge!) and assign that state to
> a vrbl.  So we

This makes sense, although it implies a "running state" is necessary for
this to work.  In the case of transfering control to somewhere you have
never been before (eg, a goto or a new function call) how does this work?

Your example:
> def test():
>     i = 0
>     global continuation
>     continuation = magic to resume at the start of the next line
>     i = i + 1
>     return i

My main problem is that this looks closer to your description of a kind-of
one-sided coroutine - ie, instead of only being capable of transfering
control, you can assign the state.  I can understand that fine.  But in the
example, the function _is_ aware its state is being captured - indeed, it
is explicitely capturing it.

My only other slight conceptual problem was how you implement functions, as
I dont understand how the concept of return values fits in at all.  But Im
sure that would become clearer when the rest of the mud is wiped from my
eyes.

And one final question:  In the context of your tutorial, what do Chris'
latest patches arm us with?  Given my new-found expertise in this matter
<wink> I would guess that the guts is there to have at least co-routines,
as capturing the state of a running Python program, and restarting it later
is possible.  Im still unclear about continuations WRT "without the
co-routines knowledge", so really unsure what is needed here...

The truly final question:-) Assuming Chris' patches were 100% bug free and
reliable (Im sure they are very close :-) what would the next steps be to
take advantage of it in a "clean" way?  ie, assuming Guido blesses them,
what exactly could I do in Python?  (All I really know is that the C stack
has gone - thats it!)

Thanks for the considerable time it must be taking to enlightening us!

Mark.