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@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