Jeremy Hylton wrote:
"CT" == Christian Tismer <tismer@appliedbiometrics.com> writes:
CT> What I want to achieve is that I can run this again, from my CT> snapshot. But with shared locals, my parameter x of the snapshot CT> would have changed to x+1, which I don't find useful. I want to CT> fix a state of the current frame and still think it should "own" CT> its locals. Globals are borrowed, anyway. Class instances will CT> anyway do what you want, since the local "self" is a mutable CT> object.
CT> How do you want to keep computations independent when locals are CT> shared? For me it's just easier to implement and also to think CT> with the shallow copy. Otherwise, where is my private place? CT> Open for becoming convinced, of course :-)
I think you're making things a lot more complicated by trying to instantiate new variable bindings for locals every time you create a continuation. Can you give an example of why that would be helpful?
I'm not sure wether you all understand me, and vice versa. There is no copying at all, but for the frame. I copy the frame, which means I also incref all the objects which it holds. Done. This is the bare minimum which I must do.
(Ok. I'm not sure I can offer a good example of why it would be helpful to share them, but it makes intuitive sense to me.)
The call_cc mechanism is going to let you capture the current continuation, save it somewhere, and call on it again as often as you like. Would you get a fresh locals each time you used it? or just the first time? If only the first time, it doesn't seem that you've gained a whole lot.
call_cc does a copy of the state which is the frame. This is stored away until it is revived. Nothing else happens. As Guido pointed out, virtually the whole frame chain is duplicated, but only on demand.
Also, all the locals that are references to mutable objects are already effectively shared. So it's only a few oddballs like ints that are an issue.
Simply look at a frame, what it is. What do you need to do to run it again with a given state. You have to preserve the stack variables. And you have to preserve the current locals, since some of them might even have a copy on the stack, and we want to stay consistent. I believe it would become obvious if you tried to implement it. Maybe I should close my ears and get something ready to show? 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