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

[Ken Manheimer]

Hokay.  I *think* i have this, and i have a question to followup.

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.  Your final
example is where that's most apparent for me:

Tim presented:
> [...]
> The continuation of (c 12) includes printing "Tim lied!", but invoking a
> continuation *abandons* the current continuation in favor of the invoked
> one.  Printing "Tim lied!" wasn't part of c's future, so that nasty slur
> about Tim never gets executed.  But:
>
> > (define liar #f)
> > (begin
>     (call/cc (lambda (k)
>                (set! liar k)
>                (c 12)))
>     (display "Tim lied!")
>     (newline))
> 13
> > (liar 666)
> Tim lied!
> >
>
> This is why I stick to trivial examples <wink>.

Though not quite as simple, i think this nailed the distinction for me.
(Too bad that i'm probably mistaken:-)

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

If we're deep in a call stack, seems like there can be a lot of
lexical-bindings baggage, plus whatever i-don't-know-how-big-it-is control
logic there is/was/will be pending.  Does the size of these things
(continuations) vary extremely, and is the variation anticipatable?  I'm
used to some surprises about the depth to which some call or other may go, i
don't expect as much uncertainty about my objects - and it seems like
continuations directly transform the call depth/complexity into data
size/complexity...  ??

unfamiliar-territory,how-far-can-i-fall?-ly,

Ken
klm@digicool.com