Piers Cawley <[EMAIL PROTECTED]> writes:

> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>> Piers Cawley <[EMAIL PROTECTED]> wrote:
>>> So, I'm trying to get my head 'round parrot's continuations. It's my
>>> understanding that, at creation time, a Continuation closes over the
>>> current user stacks, control stack and lexical pad (and possibly some
>>> other stuff but those'll do for now).
>>
>> Yes register stacks. Which is one problem of your code. The calling
>> sequence has a "savetop" inside, which isn't in the Continuations
>> context.
>
> But why do I need the savetop? I only care about the

Oops... what happened to that sentence?

Anyhoo, I looked again at the generated .pasm and noticed that P1 was
getting copied up to P20 so, if you don't do the savetop you're never
going to get the current continuation back. (I know, I'm telling you
something you already know). It seems to me that there's a good case for
saying that P1 should be closed over when a continuation is made and
restored when it's invoked. Not having to manage P1 explicitly until and
unless you want to promote it to a full continuation should help
enormously when you're wanting to write code that does (amongst other
things) tail call optimization because you know that, unless you've
fiddled with it yourself, P1 is always the current continuation. (Right
now you have to restore P1 from whichever hidden PMC register IMCC has
hidden it in, set up the various call registers by hand, stick the sub
in the right place and call it with invoke not invokecc. Since you don't
actually know *where* IMCC has shoved the continuation this is a little
tricky. You end up having to duplicate the work.)

Dan? Could you mandate this? Please?

Preserving self and the current function object could also be rather
handy...



    

Reply via email to