RetroSearch Browse

Fri May 21 09:21:22 CEST 1999 · https://mail.python.org/pipermail/python-dev/1999-May/095273.html

Jeremy Hylton wrote:
> 
> >>>>> "CT" == Christian Tismer <tismer at 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 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/1999-May/095273.html below:

[Python-Dev] 'stackless' python?