[Stackless] Re: [Python-Dev] Stackless pages
tismer at tismer.com
Mon Nov 6 20:20:55 CET 2000
Just van Rossum wrote:
> >I am worried, as Christian explained, about a C
> >API call that receives the "unwind token" when it isn't expecting it.
> Again, not to worry: Stackless won't throw the unwind token at you if you
> stick to the existing API. The only calls that can return the unwind token
> are those suffixed with _nr (as in non-recursive). I've actually been
> advocating to Chris to drop the unwind token at all, and simply give those
> *_nr calls an additional (return) argument, like so:
> Py_SomeFunction_nr(...., &unwind). This has two advantages over the current
> - it's cleaner
> - you can now return a value _and_ unwind the stack
> (the latter is also possible now, but the "return value" is then
> transported through a special field in the frame object. Hmhm.)
Yes, we discussed that in depth, but this is a minor implementation
issue. The system gets a new state, and we need to express this
somehow. Whether via a token or something else doesn't matter.
What does matter is the following:
> The disadvantage (according to Chris) is that it requires more
> modifications to the existing Python code base, as the unwind token can
> pass through existing code. I'm not sure I buy this. First it doesn't seem
> all that much code that takes advantage of this, and secondly I would feel
> uncomfortable letting the unwind token pass through code that's not aware
> of its existence.
I *only* let this pass through code that I know. I traced every
place where this can happen, and there is nothing unknown left.
Think of it like this:
This was like a rewrite of a larger piece of code by *reading*
it and not changing. I just proved that the affected code parts
would stand this trick.
I could have changed it, resulting in more changes, nothing else.
But I admit that the stuff might be more understandable by
explicitly handling the extra system state. I can do this,
after I know that the patches will make it into the distro, then.
Without knowing that, not changing but reading was cheaper for me :-)
> >While we're going for a full disclosure of things I don't understand
> >:-), I hope someone will explain why the continuation interface is so
> >much more complicated than call/cc. If Python were to adopt a
> >continuation interface, it would seem desirable to use the same
> >interface as Scheme and ML, two languages with long experience using
> >continuations (mostly to implement threads and exceptions).
> I couldn't agree more with you! The argument against call/cc in Python --
> which I would call apply_cc() instead -- is that it would be less useful in
> Python because scopes don't nest. I don't agree with that, as it's simple
> to have apply_cc() take additional arguments. Oh, and now that you're
> tackling the nested scopes issue, the argument may get even weaker...
Please show us how you use apply_cc instead of the (admittedly imperfect)
current "API" without creating more cycles.
In another thread, please.
> There's one IMHO major problem with Chris' continuation API: continuations
> aren't immutable, in the sense that they can point to a different places
> within an execution frame at different times, due to the co.update()
> method. It muddles the semantics, as it forces users to think in terms of
> _frames_ in order to understand what's going on. Continuations are the
> abstraction, frames are the implementation. Mixing the two only makes it
> more complicated.
Please don't shift the topic into the continuation design issue.
Mixing the two stories makes both less understandable.
Challenge: co.update() can be replaced by a python surrogate
construct that uses immutable coninuations only. How? :-)
ciao - chris
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless