[Python-Dev] 'stackless' python?

[Christian Tismer]

Tim Peters wrote:
> 
> [Christian]
> [... clarified stuff ... thanks! ... much clearer ...]

But still not clear enough, I fear.

> > ...
> > If a frame is the current state, I make it two frames to have two
> > current states.  One will be saved, the other will be run. This is
> > what I call "splitting".  Actually, splitting must occour whenever
> > a frame can be reached twice, in order to keep elements alive.
> 
> That part doesn't compute:  if a frame can be reached by more than one path,
> its refcount must be at least equal to the number of its immediate
> predecessors, and its refcount won't fall to 0 before it becomes
> unreachable.  So while you may need to split stuff for *some* reasons, I
> can't see how keeping elements alive could be one of those reasons (unless
> you're zapping frame contents *before* the frame itself is garbage?).

I was saying that under the side condition that I don't want to
change frames as they are now. Maybe that's misconcepted, but
this is what I did:

If a frame as we have it today shall be resumed twice, then
it has to be copied, since:
The stack is in it and has some state which will change
after resuming.

That was the whole problem with my first prototype, which
was done hoping that I don't need to change the interpreter
at all. Wrong, bad, however.

What I actually did was more than seems to be needed:
I made a copy of the whole current frame chain. Later on,
Guido said this can be done on demand. He's right.

[Scheme sample - understood]

> GETLOCAL and SETLOCAL simply index off of the fastlocals pointer; it doesn't
> care where that points *to* <wink -- but, really, it could point into some
> other frame and ceval2 wouldn't know the difference).  Maybe a frame entered
> due to continuation needs extra setup work?  Scheme saves itself by putting
> name-resolution and continuation info into different structures; to mimic
> the semantics, Python would need to get the same end effect.

Point taken. The pointer doesn't save time of access, it just
saves allocating another structure.
So we can use something else without speed loss.

[have to cut a little]

> So recall your uses of Icon generators instead:  like Python, Icon does have
> loops, and two-level scoping, and I routinely build loopy Icon generators
> that keep state in locals.  Here's a dirt-simple example I emailed to Sam
> earlier this week:
> 
> procedure main()
>     every result := fib(0, 1) \ 10 do
>         write(result)
> end
> 
> procedure fib(i, j)
>     local temp
>     repeat {
>         suspend i
>         temp := i + j
>         i := j
>         j := temp
>     }
> end

[prints fib series]

> If Icon restored the locals (i, j, temp) upon each fib resumption, it would
> generate a zero followed by an infinite sequence of ones(!).

Now I'm completely missing the point. Why should I want
to restore anything? At a suspend, which when done by continuations
will be done by temporarily having two identical states, one
is saved and another is continued. The continued one in your example
just returns the current value and immediately forgets about
the locals. The other one is continued later, and of course with
the same locals which were active when going asleep.

> Think of a continuation as a *paused* computation (which it is) rather than
> an *independent* one (which it isn't <wink>), and I think it gets darned
> hard to argue.

No, you get me wrong. I understand what you mean. It is just
the decision wether a frame, which will be reactivated later
as a continuation, should use a reference to locals like
the reference which it has for the globals. This causes me
a major frame redesign.

Current design:
A frame is: back chain, state, code, unpacked locals, globals, stack.

Code and globals are shared. 
State, unpacked locals and stack are private.

Possible new design:
A frame is: back chain, state, code, variables, globals, stack.

variables is: unpacked locals.

This makes the variables into an extra structure which is shared.
Probably a list would be the thing, or abusing a tuple as
a mutable object.

Hmm. I think I should get something ready, and we should
keep this thread short, or we will loose the rest of 
Guido's goodwill (if not already).

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home