Dan Sugalski <[EMAIL PROTECTED]> wrote:At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Its in and named C<returncc> since yesterday "return with current continuation".
Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago the first time. I've asked for names of the opcode. As no answer arrived I just used that name.
Fair enough. The cc's going to imply current continuation, which is going to confuse folks.
Maybe we should name it invoke_return.
>>Allowing just one additional object doesn't properly support Python,which has two optional expressions for the C<raise> statement and Python attaches a traceback object to the exception.
Hrm. Well, the traceback object could just be the interpreter structure at the time of the the exception. That'd be cheap enough to pass in. I'm fine with adding that as a second PMC parameter.
I don't think that this works. The handler continuation restores the context, which changes the interpreter context. During unwinding the control stack we should probably fill a (preconstructed) array-ish object with pointers to contexts up to the handler conext.
We'd talked at one point about swapping interpreter structures as part of sub invocation, though there wasn't any resolution to what the right way to do that was. It got tabled as part of the flareup.
Right now, I'm fine mandating that a non-invokable continuation is passed as the traceback object. If benchmarks show that we're going to require doing the swapping interpreter stuff to get non-sucky performance, or we have to do it to get reliable traceback info in the face of some exception scenarios, then we'll do it at that point. (I expect we're going to have to, but I'm fine with waiting on it for now, since it'll be transparent to bytecode and nearly all the C code)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
