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

[Tim Peters]

[Ken Manheimer]
> First, i think the crucial distinction i needed to make was the fact that
> the stuff inside the body of the call/cc is evaluated only when
> the call/cc is initially evaluated.  What constitutes the "future" of the
> continuation is the context immediately following the call/cc expression.

Right!  call/cc is short for call-with-current-continuation, and "current"
refers to the continuation of call/cc itself.  call/cc takes a function as
an argument, and passes to it its (call/cc's) *own* continuation.  This is
maximally clever and maximally confusing at first.  Christian has a less
clever way of spelling it that's likely to be less confusing too.

Note that it has to be a *little* tricky, because the obvious API

    k = gimme_a_continuation_for_here()

doesn't work.  The future of "gimme_a_..." includes binding k to the result,
so you could never invoke the continuation without stomping on k's binding.

    k = gimme_a_continuation_for_n_bytecodes_beyond_here(n)

could work, but is a bit hard to explain coherently <wink>.

> ...
> In any case, one big unknown for me is the expense of continuations.
> Just how expensive is squirreling away the future, anyway? (:-)

Christian gave a straight answer, so I'll give you the truth <wink>:  it
doesn't matter provided that you don't pay the price if you don't use it.  A
more interesting question is how much everyone will pay all the time to
support the possibility even if they don't use it.  But that question is
premature since Chris isn't yet aiming to optimize.  Even so, the answer so
far appears to be "> 0 but not much".

in-bang-for-the-buck-continuations-are-cheap-ly y'rs  - tim